draft-ietf-hip-rfc5201-bis-05.txt   draft-ietf-hip-rfc5201-bis-06.txt 
Network Working Group R. Moskowitz, Ed. Network Working Group R. Moskowitz, Ed.
Internet-Draft Verizon Internet-Draft Verizon
Obsoletes: 5201 (if approved) T. Heer Obsoletes: 5201 (if approved) T. Heer
Intended status: Standards Track RWTH Aachen University, Intended status: Standards Track RWTH Aachen University,
Expires: September 15, 2011 Communication and Distributed Expires: January 10, 2012 Communication and Distributed
Systems Group Systems Group
P. Jokela P. Jokela
Ericsson Research NomadicLab Ericsson Research NomadicLab
T. Henderson T. Henderson
The Boeing Company The Boeing Company
March 14, 2011 July 9, 2011
Host Identity Protocol Version 2 (HIPv2) Host Identity Protocol Version 2 (HIPv2)
draft-ietf-hip-rfc5201-bis-05 draft-ietf-hip-rfc5201-bis-06
Abstract Abstract
This document specifies the details of the Host Identity Protocol This document specifies the details of the Host Identity Protocol
(HIP). HIP allows consenting hosts to securely establish and (HIP). HIP allows consenting hosts to securely establish and
maintain shared IP-layer state, allowing separation of the identifier maintain shared IP-layer state, allowing separation of the identifier
and locator roles of IP addresses, thereby enabling continuity of and locator roles of IP addresses, thereby enabling continuity of
communications across IP address changes. HIP is based on a SIGMA- communications across IP address changes. HIP is based on a SIGMA-
compliant Diffie-Hellman key exchange, using public key identifiers compliant Diffie-Hellman key exchange, using public key identifiers
from a new Host Identity namespace for mutual peer authentication. from a new Host Identity namespace for mutual peer authentication.
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://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 September 15, 2011. This Internet-Draft will expire on January 10, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 41 skipping to change at page 3, line 41
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 37 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 37
5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 38 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 38
5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 39 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 39
5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 39 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 39
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 40 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 40
5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 43 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 43
5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 45 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 45
5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46
5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48
5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 49 5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 49
5.2.7. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 50 5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 50
5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 51 5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 51
5.2.9. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 53 5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.10. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 54 5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 54
5.2.11. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 55 5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 55
5.2.12. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 55 5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.13. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 56 5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 56
5.2.14. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 57 5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 57
5.2.15. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 58
5.2.16. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.17. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 59 5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2.18. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 60 5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 60
5.2.19. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 64 5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 61
5.2.20. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 64 5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 65
5.2.21. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 65 5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 65
5.2.22. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 66 5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 66
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 66 5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 67
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 67 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 67
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 68 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 68
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 71 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 69
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 72 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 72
5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 72 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 73
5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 73 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 73
5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 74 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 75
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 74 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 75
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 75 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 76
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 75 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 76
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 76
5.4.2. Other Problems with the HIP Header and Packet 5.4.2. Other Problems with the HIP Header and Packet
Structure . . . . . . . . . . . . . . . . . . . . . . 75 Structure . . . . . . . . . . . . . . . . . . . . . . 76
5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 75 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 77
5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 76 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 77
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 76 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 77
6.1. Processing Outgoing Application Data . . . . . . . . . . 77 6.1. Processing Outgoing Application Data . . . . . . . . . . 78
6.2. Processing Incoming Application Data . . . . . . . . . . 78 6.2. Processing Incoming Application Data . . . . . . . . . . 79
6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 78 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 80
6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 80 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 81
6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 80 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 81
6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 82 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 84
6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 84 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 86
6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 86 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 87
6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 87 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 88
6.6.2. Processing Incoming ICMP Protocol Unreachable 6.6.2. Processing Incoming ICMP Protocol Unreachable
Messages . . . . . . . . . . . . . . . . . . . . . . 87 Messages . . . . . . . . . . . . . . . . . . . . . . 88
6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 88 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 89
6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 89 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 90
6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 89 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 90
6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 89 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 91
6.8.1. Handling of Malformed Messages . . . . . . . . . . . 92 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 93
6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 92 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 93
6.9.1. Handling of Malformed Messages . . . . . . . . . . . 95 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 96
6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 95 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 96
6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 96 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 97
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 97 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 98
6.12.1. Handling a SEQ Parameter in a Received UPDATE 6.12.1. Handling a SEQ Parameter in a Received UPDATE
Message . . . . . . . . . . . . . . . . . . . . . . . 98 Message . . . . . . . . . . . . . . . . . . . . . . . 99
6.12.2. Handling an ACK Parameter in a Received UPDATE 6.12.2. Handling an ACK Parameter in a Received UPDATE
Packet . . . . . . . . . . . . . . . . . . . . . . . 98 Packet . . . . . . . . . . . . . . . . . . . . . . . 100
6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 99
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 99 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 100
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 99 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 100
6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 100 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 101
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 100 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 101
8. Security Considerations . . . . . . . . . . . . . . . . . . . 100 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 101
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 102
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105
11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 106 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107
11.1. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 106 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 108
11.2. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 108 11.1. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 108
11.3. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 108 11.2. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 109
11.4. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 109 11.3. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 110
11.5. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 111 11.4. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 111
11.6. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . . 111 11.5. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 111
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 111 11.6. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 113
12.1. Normative References . . . . . . . . . . . . . . . . . . 111 11.7. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . . 113
12.2. Informative References . . . . . . . . . . . . . . . . . 113 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 113
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 115 12.1. Normative References . . . . . . . . . . . . . . . . . . 113
Appendix B. Generating a Public Key Encoding from an HI . . . . 116 12.2. Informative References . . . . . . . . . . . . . . . . . 116
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 117 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 118
C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 118 Appendix B. Generating a Public Key Encoding from an HI . . . . 119
C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 118 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 119
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 118 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 120
Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 119 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 120
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 119 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 120
Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 121
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 121
1. Introduction 1. Introduction
This document specifies the details of the Host Identity Protocol This document specifies the details of the Host Identity Protocol
(HIP). A high-level description of the protocol and the underlying (HIP). A high-level description of the protocol and the underlying
architectural thinking is available in the separate HIP architecture architectural thinking is available in the separate HIP architecture
description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP
architecture proposes an alternative to the dual use of IP addresses architecture proposes an alternative to the dual use of IP addresses
as "locators" (routing labels) and "identifiers" (endpoint, or host, as "locators" (routing labels) and "identifiers" (endpoint, or host,
identifiers). In HIP, public cryptographic keys, of a public/private identifiers). In HIP, public cryptographic keys, of a public/private
skipping to change at page 6, line 28 skipping to change at page 6, line 28
desired, strong authentication between hosts at the TCP/IP stack desired, strong authentication between hosts at the TCP/IP stack
level can be obtained. level can be obtained.
This memo specifies the base HIP protocol ("base exchange") used This memo specifies the base HIP protocol ("base exchange") used
between hosts to establish an IP-layer communications context, called between hosts to establish an IP-layer communications context, called
a HIP association, prior to communications. It also defines a packet a HIP association, prior to communications. It also defines a packet
format and procedures for updating an active HIP association. Other format and procedures for updating an active HIP association. Other
elements of the HIP architecture are specified in other documents, elements of the HIP architecture are specified in other documents,
such as: such as:
o "Using the Encapsulating Security Payload (ESP) Transport Format o "Using the Encapsulating Security Payload (ESP) transport format
with the Host Identity Protocol (HIP)" [I-D.ietf-hip-rfc5202-bis]: with the Host Identity Protocol (HIP)" [I-D.ietf-hip-rfc5202-bis]:
how to use the Encapsulating Security Payload (ESP) for integrity how to use the Encapsulating Security Payload (ESP) for integrity
protection and optional encryption protection and optional encryption
o "Host Mobility with the Host Identity Protocol" o "Host Mobility with the Host Identity Protocol"
[I-D.ietf-hip-rfc5206-bis]: how to support host mobility in HIP [I-D.ietf-hip-rfc5206-bis]: how to support host mobility in HIP
o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions"
[I-D.ietf-hip-rfc5205-bis]: how to extend DNS to contain Host [I-D.ietf-hip-rfc5205-bis]: how to extend DNS to contain Host
Identity information Identity information
skipping to change at page 10, line 32 skipping to change at page 10, line 32
Identity (HI). Correspondingly, the host itself is defined as the Identity (HI). Correspondingly, the host itself is defined as the
entity that holds the private key of the key pair. See the HIP entity that holds the private key of the key pair. See the HIP
architecture specification [I-D.ietf-hip-rfc4423-bis] for more architecture specification [I-D.ietf-hip-rfc4423-bis] for more
details on the difference between an identity and the corresponding details on the difference between an identity and the corresponding
identifier. identifier.
HIP implementations MUST support the Rivest Shamir Adelman (RSA) HIP implementations MUST support the Rivest Shamir Adelman (RSA)
[RFC3110] public key algorithm, and SHOULD support the Digital [RFC3110] public key algorithm, and SHOULD support the Digital
Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve
Digital Signature Algorithm (ECDSA) for generating the HI as defined Digital Signature Algorithm (ECDSA) for generating the HI as defined
in Section 5.2.8. Additional algorithms MAY be supported. in Section 5.2.9. Additional algorithms MAY be supported.
A hashed encoding of the HI, the Host Identity Tag (HIT), is used in A hashed encoding of the HI, the Host Identity Tag (HIT), is used in
protocols to represent the Host Identity. The HIT is 128 bits long protocols to represent the Host Identity. The HIT is 128 bits long
and has the following three key properties: i) it is the same length and has the following three key properties: i) it is the same length
as an IPv6 address and can be used in fixed address-sized fields in as an IPv6 address and can be used in fixed address-sized fields in
APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it
is computationally hard to find a Host Identity key that matches the is computationally hard to find a Host Identity key that matches the
HIT), and iii) the probability of a HIT collision between two hosts HIT), and iii) the probability of a HIT collision between two hosts
is very low, hence, it is infeasible for an attacker to find a is very low, hence, it is infeasible for an attacker to find a
collision with a HIT that is in use. For details on the security collision with a HIT that is in use. For details on the security
skipping to change at page 11, line 48 skipping to change at page 11, line 48
OGA field, a hosts can tell from another host's HIT, whether it OGA field, a hosts can tell from another host's HIT, whether it
supports the necessary hash and signature algorithms to establish a supports the necessary hash and signature algorithms to establish a
HIP association with that host. HIP association with that host.
3.2. Generating a HIT from an HI 3.2. Generating a HIT from an HI
The HIT MUST be generated according to the ORCHID generation method The HIT MUST be generated according to the ORCHID generation method
described in [I-D.ietf-hip-rfc4843-bis] using a context ID value of described in [I-D.ietf-hip-rfc4843-bis] using a context ID value of
0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been
generated randomly by the editor of this specification), and an input generated randomly by the editor of this specification), and an input
that encodes the Host Identity field (see Section 5.2.8) present in a that encodes the Host Identity field (see Section 5.2.9) present in a
HIP payload packet. The set of hash function, signature algorithm, HIP payload packet. The set of hash function, signature algorithm,
and the algorithm used for generating the HIT from the HI depends on and the algorithm used for generating the HIT from the HI depends on
the HIT Suite (see Appendix E) and is indicated by the four bits of the HIT Suite (see Appendix E) and is indicated by the four bits of
the ORCHID Generation Algorithm (OGA) field in the ORCHID. the ORCHID Generation Algorithm (OGA) field in the ORCHID.
Currently, truncated SHA-1 and truncated SHA-256 [FIPS.180-2.2002] Currently, truncated SHA-1 and truncated SHA-256 [FIPS.180-2.2002]
are defined as hashes for generating a HIT. are defined as hashes for generating a HIT.
For identities that are either RSA, Digital Signature Algorithm For identities that are either RSA, Digital Signature Algorithm
(DSA), or Elliptic Curve DSA (ECDSA) public keys, the ORCHID input (DSA), or Elliptic Curve DSA (ECDSA) public keys, the ORCHID input
consists of the public key encoding as specified in Section 5.2.8. consists of the public key encoding as specified for the Host
This document defines four algorithm profiles: RSA, DSA, ECDSA, and Identity field of the HOST_ID parameter (see Section 5.2.9). This
document defines four algorithm profiles: RSA, DSA, ECDSA, and
ECDSA_LOW. The ECDSA_LOW profile is meant for devices with low ECDSA_LOW. The ECDSA_LOW profile is meant for devices with low
computational capabilities. There are currently only three defined computational capabilities. There are currently only three defined
public key algorithm classes: RSA/SHA-1, DSA, and ECDSA. Hence, public key algorithm classes: RSA/SHA-1, DSA, and ECDSA. Hence,
either of the following applies: either of the following applies:
The RSA public key is encoded as defined in [RFC3110] Section 2, The RSA public key is encoded as defined in [RFC3110] Section 2,
taking the exponent length (e_len), exponent (e), and modulus (n) taking the exponent length (e_len), exponent (e), and modulus (n)
fields concatenated. The length (n_len) of the modulus (n) can be fields concatenated. The length (n_len) of the modulus (n) can be
determined from the total HI Length and the preceding HI fields determined from the total HI Length and the preceding HI fields
including the exponent (e). Thus, the data that serves as input including the exponent (e). Thus, the data that serves as input
skipping to change at page 16, line 15 skipping to change at page 16, line 15
provided #J, and compute the hash once to prove that the Initiator provided #J, and compute the hash once to prove that the Initiator
completed its assigned task. completed its assigned task.
To prevent precomputation attacks, the Responder MUST select the To prevent precomputation attacks, the Responder MUST select the
number #I in such a way that the Initiator cannot guess it. number #I in such a way that the Initiator cannot guess it.
Furthermore, the construction MUST allow the Responder to verify that Furthermore, the construction MUST allow the Responder to verify that
the value #I was indeed selected by it and not by the Initiator. See the value #I was indeed selected by it and not by the Initiator. See
Appendix A for an example on how to implement this. Appendix A for an example on how to implement this.
Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an
ECHO_REQUEST_SIGNED (see Section 5.2.19) or in an ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an
ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.20), the Responder ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder
can include some data in R1 that the Initiator MUST copy unmodified can include some data in R1 that the Initiator MUST copy unmodified
in the corresponding I2 packet. The Responder can use the opaque in the corresponding I2 packet. The Responder can use the opaque
data to transfer a piece of local state information to the Initiator data to transfer a piece of local state information to the Initiator
and back, for example to recognize that the I2 is a response to a and back, for example to recognize that the I2 is a response to a
previously sent R1. The Responder can generate the Opaque data in previously sent R1. The Responder can generate the Opaque data in
various ways; e.g., using encryption or hashing with some secret, the various ways; e.g., using encryption or hashing with some secret, the
sent #I, and possibly using other related data. With the same sent #I, and possibly using other related data. With the same
secret, the received #I (from the I2 packet), and the other related secret, the received #I (from the I2 packet), and the other related
data (if any), the Responder can verify that it has itself sent the data (if any), the Responder can verify that it has itself sent the
#I to the Initiator. The Responder MUST periodically change such a #I to the Initiator. The Responder MUST periodically change such a
skipping to change at page 16, line 49 skipping to change at page 16, line 49
The puzzle value #I and the solution #J are inputs for deriving the The puzzle value #I and the solution #J are inputs for deriving the
keying material from the Diffie-Hellman key exchange (see keying material from the Diffie-Hellman key exchange (see
Section 6.5). Therefore, a Responder SHOULD NOT use the same puzzle Section 6.5). Therefore, a Responder SHOULD NOT use the same puzzle
#I with the same DH keys for the same Initiator twice to ensure that #I with the same DH keys for the same Initiator twice to ensure that
the derived keying material differs. Such uniqueness can be the derived keying material differs. Such uniqueness can be
achieved, for example, by using a counter as an additional input for achieved, for example, by using a counter as an additional input for
generating #I. This counter can be increased for each processed I1 generating #I. This counter can be increased for each processed I1
packet. The state of the counter can be transmitted in the Opaque packet. The state of the counter can be transmitted in the Opaque
data field in the PUZZLE (see Section 5.2.4), in an data field in the PUZZLE (see Section 5.2.4), in an
ECHO_REQUEST_SIGNED (see Section 5.2.19) or in an ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an
ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.20) without the need ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21) without the need
to establish state. to establish state.
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 to NOT include a timestamp to avoid attacks. The decision was to NOT include a timestamp to avoid
problems with global time synchronization. problems with global time synchronization.
NOTE: The protocol developers explicitly considered whether a memory NOTE: The protocol developers explicitly considered whether a memory
bound function should be used for the puzzle instead of a CPU-bound bound function should be used for the puzzle instead of a CPU-bound
function. The decision was not to use memory-bound functions. function. The decision was not to use memory-bound functions.
skipping to change at page 36, line 29 skipping to change at page 36, line 29
Other documents may define how to include user data in various HIP Other documents may define how to include user data in various HIP
packets. However, currently the HIP header is a terminal header, and packets. However, currently the HIP header is a terminal header, and
not followed by any other headers. not followed by any other headers.
4.5.3. Transport Formats 4.5.3. Transport Formats
The actual data transmission format, used for user data after the HIP The actual data transmission format, used for user data after the HIP
base exchange, is not defined in this document. Such transport base exchange, is not defined in this document. Such transport
formats and methods are described in separate specifications. All formats and methods are described in separate specifications. All
HIP implementations MUST implement, at minimum, the ESP transport HIP implementations MUST implement, at minimum, the ESP transport
format for HIP [I-D.ietf-hip-rfc5202-bis]. format for HIP [I-D.ietf-hip-rfc5202-bis]. The transport format to
be chosen is negotiated in the base exchange. The Responder
expresses its preference of the transport format in the
TRANSPORT_FORMAT_LIST in the R1 packet and the Initiator selects one
transform and adds the respective HIP parameter to the I2 packet.
4.5.4. Reboot, Timeout, and Restart of HIP 4.5.4. Reboot, Timeout, and Restart of HIP
Simulating a loss of state is a potential DoS attack. The following Simulating a loss of state is a potential DoS attack. The following
process has been crafted to manage state recovery without presenting process has been crafted to manage state recovery without presenting
a DoS opportunity. a DoS opportunity.
If a host reboots or the HIP association times out, it has lost its If a host reboots or the HIP association times out, it has lost its
HIP state. If the host that lost state has a datagram to send to the HIP state. If the host that lost state has a datagram to send to the
peer, it simply restarts the HIP base exchange. After the base peer, it simply restarts the HIP base exchange. After the base
skipping to change at page 39, line 28 skipping to change at page 39, line 31
packet and capabilities of the host. packet and capabilities of the host.
The following fields have been defined: The following fields have been defined:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | |A| | | | | | | | | | | | | | | | |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 using
I2. The peer receiving an anonymous HI may choose to refuse it. anonymous sender HIs. The peer receiving an anonymous HI in an R1
or I2 may choose to refuse it.
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 in sent packets and ignored in received packets. zero in sent packets and ignored in received packets.
5.1.3. HIP Fragmentation Support 5.1.3. 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 is REQUIRED to be implemented in IPv4 (IPv4 fragment generation is REQUIRED to be implemented in IPv4 (IPv4
stacks and networks will usually do this by default) and RECOMMENDED stacks and networks will usually do this by default) and RECOMMENDED
skipping to change at page 41, line 5 skipping to change at page 41, line 5
included in HIP parameters. The specification of the HIP parameters included in HIP parameters. The specification of the HIP parameters
and their mapping to HIP packets and packet types is flexible to and their mapping to HIP packets and packet types is flexible to
allow HIP extensions to define new parameters and new protocol allow HIP extensions to define new parameters and new protocol
behavior. behavior.
In HIP packets, HIP parameters are ordered according to their numeric In HIP packets, HIP parameters are ordered according to their numeric
type number and encoded in TLV format. type number and encoded in TLV format.
The following parameter types are currently defined. The following parameter types are currently defined.
+------------------------+-------+----------+-----------------------+ +------------------------+-------+-----------+----------------------+
| TLV | Type | Length | Data | | TLV | Type | Length | Data |
+------------------------+-------+----------+-----------------------+ +------------------------+-------+-----------+----------------------+
| R1_COUNTER | 128 | 12 | Puzzle generation | | R1_COUNTER | 128 | 12 | Puzzle generation |
| | | | counter | | | | | counter |
| | | | | | | | | |
| PUZZLE | 257 | 12 | K and Random #I | | PUZZLE | 257 | 12 | K and Random #I |
| | | | | | | | | |
| SOLUTION | 321 | 20 | K, Random #I and | | SOLUTION | 321 | 20 | K, Random #I and |
| | | | puzzle solution J | | | | | puzzle solution J |
| | | | | | | | | |
| SEQ | 385 | 4 | UPDATE packet ID | | SEQ | 385 | 4 | UPDATE packet ID |
| | | | number | | | | | number |
| | | | | | | | | |
| ACK | 449 | variable | UPDATE packet ID | | ACK | 449 | variable | UPDATE packet ID |
| | | | number | | | | | number |
| | | | | | | | | |
| DIFFIE_HELLMAN | 513 | variable | public key | | DH_GROUP_LIST | 511 | variable | Ordered list of DH |
| | | | | | | | | Group IDs supported |
| HIP_CIPHER | 579 | variable | List of HIP | | | | | by a host |
| | | | encryption algorithms | | | | | |
| | | | | | DIFFIE_HELLMAN | 513 | variable | public key |
| ENCRYPTED | 641 | variable | Encrypted part of a | | | | | |
| | | | HIP packet | | HIP_CIPHER | 579 | variable | List of HIP |
| | | | | | | | | encryption |
| HOST_ID | 705 | variable | Host Identity with | | | | | algorithms |
| | | | Fully-Qualified | | | | | |
| | | | Domain FQDN (Name) or | | ENCRYPTED | 641 | variable | Encrypted part of a |
| | | | Network Access | | | | | HIP packet |
| | | | Identifier (NAI) | | | | | |
| | | | | | HOST_ID | 705 | variable | Host Identity with |
| HIT_SUITE_LIST | 715 | variable | Ordered list of the | | | | | Fully-Qualified |
| | | | HIT suites supported | | | | | Domain FQDN (Name) |
| | | | by the Responder | | | | | or Network Access |
| | | | | | | | | Identifier (NAI) |
| CERT | 768 | variable | HI Certificate; used | | | | | |
| | | | to transfer | | HIT_SUITE_LIST | 715 | variable | Ordered list of the |
| | | | certificates. | | | | | HIT suites supported |
| | | | Specified in a | | | | | by the Responder |
| | | | separate docment. | | | | | |
| | | | | | CERT | 768 | variable | HI Certificate; used |
| NOTIFICATION | 832 | variable | Informational data | | | | | to transfer |
| | | | | | | | | certificates. |
| ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | | | | | Specified in a |
| | | | echoed back; signed | | | | | separate docment. |
| | | | | | | | | |
| ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | | NOTIFICATION | 832 | variable | Informational data |
| | | | back; signed | | | | | |
| DH_GROUP_LIST | 2151 | variable | Ordered list of DH | | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be |
| | | | Group IDs supported | | | | | echoed back; signed |
| | | | by a host | | | | | |
| | | | | | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed |
| HIP_MAC | 61505 | variable | HMAC-based message | | | | | back by request; |
| | | | authentication code, | | | | | signed |
| | | | with key material | | | | | |
| | | | from KEYMAT | | TRANSPORT_FORMAT_LIST | 2049 | Ordered | variable |
| | | | | | | | list of | |
| HIP_MAC_2 | 61569 | variable | HMAC based message | | | | preferred | |
| | | | authentication code, | | | | HIP | |
| | | | with key material | | | | transport | |
| | | | from KEYMAT. Unlike | | | | type | |
| | | | HIP_MAC, the HOST_ID | | | | numbers | |
| | | | parameter is included | | | | | |
| | | | in HIP_MAC_2 | | HIP_MAC | 61505 | variable | HMAC-based message |
| | | | calculation. | | | | | authentication code, |
| | | | | | | | | with key material |
| HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 | | | | | from KEYMAT |
| | | | packet | | | | | |
| | | | | | HIP_MAC_2 | 61569 | variable | HMAC based message |
| HIP_SIGNATURE | 61697 | variable | Signature of the | | | | | authentication code, |
| | | | packet | | | | | with key material |
| | | | | | | | | from KEYMAT. Unlike |
| ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be | | | | | HIP_MAC, the HOST_ID |
| | | | echoed back; after | | | | | parameter is |
| | | | signature | | | | | included in |
| | | | | | | | | HIP_MAC_2 |
| ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed | | | | | calculation. |
| | | | back by request; | | | | | |
| | | | after signature | | HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 |
+------------------------+-------+----------+-----------------------+ | | | | packet |
| | | | |
| HIP_SIGNATURE | 61697 | variable | Signature of the |
| | | | packet |
| | | | |
| ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be |
| | | | echoed back; after |
| | | | signature |
| | | | |
| ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed |
| | | | back by request; |
| | | | after signature |
+------------------------+-------+-----------+----------------------+
As the ordering (from lowest to highest) of HIP parameters is As the ordering (from lowest to highest) of HIP parameters is
strictly enforced (see Section 5.2.1), the parameter type values for strictly enforced (see Section 5.2.1), the parameter type values for
existing parameters have been spaced to allow for future protocol existing parameters have been spaced to allow for future protocol
extensions. extensions.
The following parameter type number ranges are defined. The following parameter type number ranges are defined.
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| Type Range | Purpose | | Type Range | Purpose |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| 0 - 1023 | Handshake | | 0 - 1023 | Handshake |
| | | | | |
| 1024 - 2047 | Reserved | | 1024 - 2047 | Reserved |
| | | | | |
| 2048 - 4095 | Parameters related to HIP transport types | | 2048 - 4095 | Parameters related to HIP transport formats |
| | | | | |
| 4096 - 8191 | Signed parameters allocated through specification | | 4096 - 8191 | Signed parameters allocated through specification |
| | documents | | | documents |
| | | | | |
| 8192 - 32767 | Reserved | | 8192 - 32767 | Reserved |
| | | | | |
| 32768 - 49151 | Free for experimentation. Signed parameters. | | 32768 - 49151 | Free for experimentation. Signed parameters. |
| | | | | |
| 41952 - 61439 | Reserved | | 41952 - 61439 | Reserved |
| | | | | |
skipping to change at page 43, line 45 skipping to change at page 43, line 48
of this document. of this document.
The range between 32768 (2^15) and 49151 (2^15 + 2^14) are free for The range between 32768 (2^15) and 49151 (2^15 + 2^14) are free for
experimentation. Types from this range SHOULD be selected in a experimentation. Types from this range SHOULD be selected in a
random fashion to reduce the probability of collisions. random fashion to reduce the probability of collisions.
5.2.1. TLV Format 5.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, except for type values from 2048 to 4095 which fields in the packet. The parameters MUST be included in the packet
are reserved for new transport forms. The parameters MUST be so that their types form an increasing order. If multiple parameters
included in the packet so that their types form an increasing order. with the same type number are in one packet, the parameters with the
If multiple parameters with the same type number are in one packet, same type MUST be consecutive in the packet. If the order does not
the parameters with the same type MUST be consecutive in the packet. follow this rule, the packet is considered to be malformed and it
If the order does not follow this rule, the packet is considered to MUST be discarded.
be malformed and it MUST be discarded.
Parameters using type values from 2048 up to 4095 are transport Parameters using type values from 2048 up to 4095 are related to
formats. Currently, one transport format is defined: the ESP transport formats. Currently, one transport format is defined: the
transport format [I-D.ietf-hip-rfc5202-bis]. The order of these ESP transport format [I-D.ietf-hip-rfc5202-bis].
parameters does not follow the order of their type value, but they
are put in the packet in order of preference. The first of the
transport formats it the most preferred, and so on.
All of the encoded TLV parameters have a length (that includes the All of the encoded TLV parameters have a length (that includes the
Type and Length fields), which is a multiple of 8 bytes. When Type and Length fields), which is a multiple of 8 bytes. When
needed, padding MUST be added to the end of the parameter so that the needed, padding MUST be added to the end of the parameter so that the
total length is a multiple of 8 bytes. This rule ensures proper total length is a multiple of 8 bytes. This rule ensures proper
alignment of data. Any added padding bytes MUST be zeroed by the alignment of data. Any added padding bytes MUST be zeroed by the
sender, and their values SHOULD NOT be checked by the receiver. sender, and their values SHOULD NOT be checked by the receiver.
The Length field indicates the length of the Contents field (in The Length field indicates the length of the Contents field (in
bytes). Consequently, the total length of the TLV parameter bytes). Consequently, the total length of the TLV parameter
skipping to change at page 49, line 5 skipping to change at page 49, line 5
Puzzle solution #J random number of size RHASH_len bits Puzzle solution #J random number of size RHASH_len bits
Random #I and Random #J are represented as n-bit unsigned integers Random #I and Random #J are represented as n-bit unsigned integers
(where n is RHASH_len), #K as an 8-bit unsigned integer, all in (where n is RHASH_len), #K as an 8-bit unsigned integer, all in
network byte order. network byte order.
The SOLUTION parameter contains a solution to a puzzle. It also The SOLUTION parameter contains a solution to a puzzle. It also
echoes back the random difficulty #K, the Opaque field, and the echoes back the random difficulty #K, the Opaque field, and the
puzzle integer #I. puzzle integer #I.
5.2.6. DIFFIE_HELLMAN 5.2.6. DH_GROUP_LIST
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH GROUP ID #n| Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 511
Length number of DH Group IDs
DH GROUP ID defines a DH GROUP ID supported by the host.
The list of IDs is ordered by preference of the
host. The list of define DH Group IDs in the
DIFFIE_HELLMAN parameter. Each DH Group ID is one
octet long.
The DH_GROUP_LIST parameter contains the list of supported DH Group
IDs of a host. The Initiator sends the DH_GROUP_LIST in the I1
packet, the Responder sends its own list in the signed part of the R1
packet. The DH Group IDs in the DH_GROUP_LIST are listed in the
order of their preference of the host sending the list. DH Group IDs
that are listed first are preferred over the DH Group IDs listed
later. The information in the DH_GROUP_LIST allows the Responder to
select the DH group preferred by itself and supported by the
Initiator. Based on the DH_GROUP_LIST in the R1 packet, the
Initiator can determine if the Responder has selected the best
possible choice based on the Initiator's and Responder's preferences.
If the Responder's choice differs from the best choice, the Initiator
can conclude that there was an attempted downgrade attack (see
Section 4.1.7).
When selecting the DH group for the DIFFIE_HELLMAN parameter in the
R1 packet, the Responder MUST select the first DH Group ID in its
DH_GROUP_LIST in the R1 packet that is compatible with one of the
Suite IDs in the Initiator's DH_GROUP_LIST in the I1 packet. The
Responder MUST NOT select any other DH Group ID that is contained in
both lists because a downgrade attack cannot be detected then.
In general, hosts SHOULD prefer stronger groups over weaker ones if
the computation overhead is not prohibitively high for the intended
application.
5.2.7. DIFFIE_HELLMAN
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 Length | Public Value / | Group ID | Public Value Length | Public Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 50, line 6 skipping to change at page 51, line 6
A HIP implementation MUST implement Group ID 3. The 160-bit A HIP implementation MUST implement Group ID 3. The 160-bit
SECP160R1 group can be used when lower security is enough (e.g., web SECP160R1 group can be used when lower security is enough (e.g., web
surfing) and when the equipment is not powerful enough (e.g., some surfing) and when the equipment is not powerful enough (e.g., some
PDAs). Implementations SHOULD implement Group IDs 4 and 8. PDAs). Implementations SHOULD implement Group IDs 4 and 8.
To avoid unnecessary failures during the base exchange, the rest of To avoid unnecessary failures during the base exchange, the rest of
the groups SHOULD be implemented in hosts where resources are the groups SHOULD be implemented in hosts where resources are
adequate. adequate.
5.2.7. HIP_CIPHER 5.2.8. HIP_CIPHER
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cipher ID #1 | Cipher ID #2 | | Cipher ID #1 | Cipher ID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cipher ID #n | Padding | | Cipher ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 50, line 50 skipping to change at page 51, line 50
default configuration, the HIP_CIPHER parameter MUST contain at least default configuration, the HIP_CIPHER parameter MUST contain at least
one of the mandatory Cipher IDs. There MAY be a configuration option one of the mandatory Cipher IDs. There MAY be a configuration option
that allows the administrator to override this default. that allows the administrator to override this default.
The Responder lists supported and desired Cipher IDs in order of The Responder lists supported and desired Cipher IDs in order of
preference in the R1, up to the maximum of six Cipher IDs. The preference in the R1, up to the maximum of six Cipher IDs. The
Initiator MUST choose only one of the corresponding Cipher IDs. This Initiator MUST choose only one of the corresponding Cipher IDs. This
Cipher ID will be used for generating the ENCRYPTED parameter. Cipher ID will be used for generating the ENCRYPTED parameter.
Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION is included Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION is included
for testing purposes. NULL-ENCRYPTION SHOULD NOT be configurable via for testing purposes.
the UI.
5.2.8. HOST_ID 5.2.9. HOST_ID
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HI Length |DI-type| DI Length | | HI Length |DI-type| DI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Host Identity / | Algorithm | Host Identity /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Domain Identifier / / | Domain Identifier /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding | / | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 705 Type 705
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
Padding Padding
HI Length length of the Host Identity in octets HI Length length of the Host Identity in octets
DI-type type of the following Domain Identifier field DI-type type of the following Domain Identifier field
Algorithm index to the employed algorithm
DI Length length of the Domain Identifier field in octets DI Length length of the Domain Identifier field in octets
Algorithm index to the employed algorithm
Host Identity actual Host Identity Host Identity actual Host Identity
Domain Identifier the identifier of the sender Domain Identifier the identifier of the sender
The following DI-types have been defined: The following DI-types have been defined:
Type Value Type Value
none included 0 none included 0
FQDN 1 FQDN 1
NAI 2 NAI 2
skipping to change at page 53, line 5 skipping to change at page 54, line 5
ECDSA NIST P-384 2 [RFC4754] ECDSA NIST P-384 2 [RFC4754]
For hosts that implement the EDSA_LOW algorithm profile, the For hosts that implement the EDSA_LOW algorithm profile, the
following curve is required: following curve is required:
Algorithm Curve Values Algorithm Curve Values
ECDSA_LOW RESERVED 0 ECDSA_LOW RESERVED 0
ECDSA_LOW SECP160R1 1 [SECG] ECDSA_LOW SECP160R1 1 [SECG]
5.2.9. HIT_SUITE_LIST 5.2.10. HIT_SUITE_LIST
The HIT_SUITE_LIST parameter contains a list of the supported HIT The HIT_SUITE_LIST parameter contains a list of the supported HIT
suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST
in the signed part of the R1 packet. Based on the HIT_SUITE_LIST, in the signed part of the R1 packet. Based on the HIT_SUITE_LIST,
the Initiator can determine which source HITs are supported by the the Initiator can determine which source HITs are supported by the
Responder. Responder.
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 53, line 34 skipping to change at page 54, line 34
Length number of HIT Suite IDs Length number of HIT Suite IDs
ID defines a HIT Suite ID supported by the host. ID defines a HIT Suite ID supported by the host.
The list of IDs is ordered by preference of the The list of IDs is ordered by preference of the
host. Each HIT Suite ID is one octet long. The four host. Each HIT Suite ID is one octet long. The four
higher-order bits of the ID field correspond to the higher-order bits of the ID field correspond to the
HIT Suite ID in the ORCHID OGA field. The four HIT Suite ID in the ORCHID OGA field. The four
lower-order bits are reserved and set to 0 and lower-order bits are reserved and set to 0 and
ignored by the receiver. ignored by the receiver.
The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of
signature algorithms as defined in Section 5.2.8 and hash functions. signature algorithms as defined in Section 5.2.9 and hash functions.
The ID field in the HIT_SUITE_LIST is defined as eight-bit field as The ID field in the HIT_SUITE_LIST is defined as eight-bit field as
opposed to the four-bit HIT Suite ID and OGA field in the ORCHID. opposed to the four-bit HIT Suite ID and OGA field in the ORCHID.
This difference is a measure to accommodate larger HIT Suite IDs if This difference is a measure to accommodate larger HIT Suite IDs if
the 16 available values prove insufficient. In that case, one of the the 16 available values prove insufficient. In that case, one of the
16 values, zero, will be used to indicate that four additional bits 16 values, zero, will be used to indicate that four additional bits
of the ORCHID will be used to encode the HIT Suite ID. Hence, the of the ORCHID will be used to encode the HIT Suite ID. Hence, the
current four-bit HIT Suite-IDs only use the four higher order bits in current four-bit HIT Suite-IDs only use the four higher order bits in
the ID field. Future documents may define the use of the four lower- the ID field. Future documents may define the use of the four lower-
order bits in the ID field. order bits in the ID field.
The following HIT Suites ID are defined: The following HIT Suites ID are defined:
HIT Suite ID HIT Suite ID
RESERVED 0 RESERVED 0
RSA,DSA/SHA-1 1 (REQUIRED) RSA,DSA/SHA-1 1 (REQUIRED)
ECDSA/SHA-384 2 (RECOMMENDED) ECDSA/SHA-384 2 (RECOMMENDED)
ECDSA_LOW/SHA-1 3 (RECOMMENDED) ECDSA_LOW/SHA-1 3 (RECOMMENDED)
5.2.10. DH_GROUP_LIST 5.2.11. TRANSPORT_FORMAT_LIST
0 1 2 3 The TRANSPORT_FORMAT_LIST parameter contains a list of the supported
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 HIP transport formats (TFs) of the Responder. The Responder sends
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the TRANSPORT_FORMAT_LIST in the signed part of the R1 packet. Based
| Type | Length | on the TRANSPORT_FORMAT_LIST, the Initiator chooses one suitable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ transport format and includes the respective HIP transport format
| DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4| parameter in its response packet.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH GROUP ID #n| Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2151 0 1 2 3
Length number of DH Group IDs 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
DH GROUP ID defines a DH GROUP ID supported by the host. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The list of IDs is ordered by preference of the | Type | Length |
host. The list of define DH Group IDs in the +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DIFFIE_HELLMAN parameter. Each DH Group ID is one | TF type #1 | TF type #2 /
octet long. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ TF type #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DH_GROUP_LIST parameter contains the list of supported DH Group Type 2049
IDs of a host. The Initiator sends the DH_GROUP_LIST in the I1 Length 2x number of TF types
packet, the Responder sends its own list in the signed part of the R1 TF Type defines a transport format (TF) type supported by the
packet. The DH Group IDs in the DH_GROUP_LIST are listed in the host. The TF type numbers correspond to the HIP
order of their preference of the host sending the list. DH Group IDs parameter type numbers of the respective transform
that are listed first are preferred over the DH Group IDs listed parameters. The list of TF types is ordered by preference
later. The information in the DH_GROUP_LIST allows the Responder to of the sender
select the DH group preferred by itself and supported by the
Initiator. Based on the DH_GROUP_LIST in the R1 packet, the
Initiator can determine if the Responder has selected the best
possible choice based on the Initiator's and Responder's preferences.
If the Responder's choice differs from the best choice, the Initiator
can conclude that there was an attempted downgrade attack (see
Section 4.1.7).
When selecting the DH group for the DIFFIE_HELLMAN parameter in the The TF type numbers index the respective HIP parameters for the
R1 packet, the Responder MUST select the first DH Group ID in its transport formats in the type number range between 2050 to 4095. The
DH_GROUP_LIST in the R1 packet that is compatible with one of the parameters and their use is defined in separate documents.
Suite IDs in the Initiator's DH_GROUP_LIST in the I1 packet. The Currently, the only transport format defined is IPsec ESP
Responder MUST NOT select any other DH Group ID that is contained in [I-D.ietf-hip-rfc5202-bis].
both lists because a downgrade attack cannot be detected then.
5.2.11. HIP_MAC For each listed TF type, the sender of the parameter MUST include the
repective transport form parameter in the HIP packet. The TF type in
the TRANSPORT_FORM_LIST MUST be ignored if no matching transport form
parameter is present in the packet.
5.2.12. HIP_MAC
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 |
/ / / /
/ +-------------------------------+ / +-------------------------------+
skipping to change at page 55, line 36 skipping to change at page 56, line 36
The checksum field MUST be set to zero and the HIP The checksum field MUST be set to zero and the HIP
header length in the HIP common header MUST be header length in the HIP common header MUST be
calculated not to cover any excluded parameters calculated not to cover any excluded parameters
when the HMAC is calculated. The size of the when the HMAC is calculated. The size of the
HMAC is the natural size of the hash computation HMAC is the natural size of the hash computation
output depending on the used hash function. output depending on the used hash function.
The HMAC uses RHASH as hash algorithm. The calculation and The HMAC uses RHASH as hash algorithm. The calculation and
verification process is presented in Section 6.4.1. verification process is presented in Section 6.4.1.
5.2.12. HIP_MAC_2 5.2.13. HIP_MAC_2
The HIP_MAC_2 is a MAC of the packet and the HOST_ID parameter of the The HIP_MAC_2 is a MAC of the packet and the HOST_ID parameter of the
sender while only the packet without HOST_ID of the sender is sent. sender while only the packet without HOST_ID of the sender is sent.
The parameter structure is the same as in Section 5.2.11. The fields The parameter structure is the same as in Section 5.2.12. The fields
are: are:
Type 61569 Type 61569
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
Padding Padding
HMAC HMAC computed over the HIP packet, excluding the HMAC HMAC computed over the HIP packet, excluding the
HIP_MAC_2 parameter and any following parameters HIP_MAC_2 parameter and any following parameters
such as HIP_SIGNATURE, HIP_SIGNATURE_2, such as HIP_SIGNATURE, HIP_SIGNATURE_2,
ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED, ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED,
and including an additional sender's HOST_ID and including an additional sender's HOST_ID
skipping to change at page 56, line 24 skipping to change at page 57, line 24
field MUST be set to zero and the HIP header length field MUST be set to zero and the HIP header length
in the HIP common header MUST be calculated not to in the HIP common header MUST be calculated not to
cover any excluded parameters when the HMAC is cover any excluded parameters when the HMAC is
calculated. The size of the HMAC is the natural calculated. The size of the HMAC is the natural
size of the hash computation output depending on the size of the hash computation output depending on the
used hash function. used hash function.
The HMAC uses RHASH as hash algorithm. The calculation and The HMAC uses RHASH as hash algorithm. The calculation and
verification process is presented in Section 6.4.1. verification process is presented in Section 6.4.1.
5.2.13. HIP_SIGNATURE 5.2.14. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 56, line 48 skipping to change at page 57, line 48
Padding 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 parameter and any excluding the HIP_SIGNATURE parameter and any
parameters that follow the HIP_SIGNATURE parameter. parameters that follow the HIP_SIGNATURE parameter.
When the signature is calculated the checksum field When the signature is calculated the checksum field
MUST be set to zero, and the HIP header length in MUST be set to zero, and the HIP header length in
the HIP common header MUST be calculated only up to the HIP common header MUST be calculated only up to
the beginning of the HIP_SIGNATURE parameter. the beginning of the HIP_SIGNATURE parameter.
The signature algorithms are defined in Section 5.2.8. The signature The signature algorithms are defined in Section 5.2.9. The signature
in the Signature field is encoded using the method depending on the in the Signature field is encoded using the method depending on the
signature algorithm (e.g., according to [RFC3110] in case of RSA/ signature algorithm (e.g., according to [RFC3110] in case of RSA/
SHA-1, according to [RFC5702] in case of RSA/SHA-256, according to SHA-1, according to [RFC5702] in case of RSA/SHA-256, according to
[RFC2536] in case of DSA, or according to [RFC6090] in case of [RFC2536] in case of DSA, or according to [RFC6090] in case of
ECDSA). ECDSA).
The HIP_SIGNATURE calculation and verification process are presented The HIP_SIGNATURE calculation and verification process are presented
in Section 6.4.2. in Section 6.4.2.
5.2.14. HIP_SIGNATURE_2 5.2.15. HIP_SIGNATURE_2
The HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet The HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet
to allow R1 pre-creation. The parameter structure is the same as in to allow R1 pre-creation. The parameter structure is the same as in
Section 5.2.13. The fields are: Section 5.2.14. The fields are:
Type 61633 Type 61633
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
Padding Padding
SIG alg signature algorithm SIG alg signature algorithm
Signature Within the R1 packet that contains the Signature Within the R1 packet that contains the
HIP_SIGNATURE_2 parameter, the Initiator's HIT, the HIP_SIGNATURE_2 parameter, the Initiator's HIT, the
checksum field, and the Opaque and Random #I fields checksum field, and the Opaque and Random #I fields
in the PUZZLE parameter MUST be set to zero while in the PUZZLE parameter MUST be set to zero while
computing the HIP_SIGNATURE_2 signature. Further, computing the HIP_SIGNATURE_2 signature. Further,
skipping to change at page 57, line 39 skipping to change at page 58, line 39
verification. verification.
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. Zeroing beforehand, to minimize the effects of possible DoS attacks. Zeroing
the Random #I and Opaque fields within the PUZZLE parameter allows the Random #I and Opaque fields within the PUZZLE parameter allows
these fields to be populated dynamically on precomputed R1s. these fields to be populated dynamically on precomputed R1s.
Signature calculation and verification follows the process defined in Signature calculation and verification follows the process defined in
Section 6.4.2. Section 6.4.2.
5.2.15. SEQ 5.2.16. SEQ
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update ID | | Update ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 385 Type 385
Length 8 Length 8
Update ID 32-bit sequence number Update ID 32-bit sequence number
The Update ID is an unsigned number in network byte order, The Update ID is an unsigned number in network byte order,
initialized by a host to zero upon moving to ESTABLISHED state. The initialized by a host to zero upon moving to ESTABLISHED state. The
Update ID has scope within a single HIP association, and not across Update ID has scope within a single HIP association, and not across
multiple associations or multiple hosts. The Update ID is multiple associations or multiple hosts. The Update ID is
incremented by one before each new UPDATE that is sent by the host; incremented by one before each new UPDATE that is sent by the host;
the first UPDATE packet originated by a host has an Update ID of 0. the first UPDATE packet originated by a host has an Update ID of 0.
5.2.16. ACK 5.2.17. ACK
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| peer Update ID 1 | | peer Update ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ peer Update ID n | / peer Update ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 449 Type 449
Length length in octets, excluding Type and Length Length length in octets, excluding Type and Length
peer Update ID 32-bit sequence number corresponding to the peer Update ID 32-bit sequence number corresponding to the
Update ID being ACKed. Update ID being ACKed.
The ACK parameter includes one or more Update IDs that have been The ACK parameter includes one or more Update IDs that have been
received from the peer. The number of peer Update IDs can be received from the peer. The number of peer Update IDs can be
inferred from the length by dividing it by 4. inferred from the length by dividing it by 4.
5.2.17. ENCRYPTED 5.2.18. 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 /
/ / / /
skipping to change at page 60, line 24 skipping to change at page 61, line 24
Note that the length of the cipher suite output may be smaller or Note that the length of the cipher suite output may be smaller or
larger than the length of the set of parameters to be encrypted, larger than the length of the set of parameters to be encrypted,
since the encryption process may compress the data or add additional since the encryption process may compress the data or add additional
padding to the data. padding to the data.
Once this encryption process is completed, the Encrypted data field Once this encryption process is completed, the Encrypted data field
is ready for inclusion in the parameter. If necessary, additional is ready for inclusion in the parameter. If necessary, additional
Padding for 8-byte alignment is then added according to the rules of Padding for 8-byte alignment is then added according to the rules of
Section 5.2.1. Section 5.2.1.
5.2.18. NOTIFICATION 5.2.19. NOTIFICATION
The NOTIFICATION parameter is used to transmit informational data, The NOTIFICATION parameter is used to transmit informational data,
such as error conditions and state transitions, to a HIP peer. A such as error conditions and state transitions, to a HIP peer. A
NOTIFICATION parameter may appear in NOTIFY packets. The use of the NOTIFICATION parameter may appear in NOTIFY packets. The use of the
NOTIFICATION parameter in other packet types is for further study. NOTIFICATION parameter in other packet types is for further study.
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 |
skipping to change at page 61, line 33 skipping to change at page 62, line 33
Type Type
Notification informational or error data transmitted in addition Notification informational or error data transmitted in addition
Data to the Notify Message Type. Values for this field Data to the Notify Message Type. Values for this field
are type specific (see below). are type specific (see below).
multiple of 8 bytes. multiple of 8 bytes.
Notification information can be error messages specifying why an HIP Notification information can be error messages specifying why an HIP
Security Association could not be established. It can also be status Security Association could not be established. It can also be status
data that a HIP implementation wishes to communicate with a peer data that a HIP implementation wishes to communicate with a peer
process. The table below lists the notification messages and their process. The table below lists the notification messages and their
Notification Message Types. HIP packets MAY contain multiple notify Notification Message Types. HIP packets MAY contain multiple
parameters if several problems exist or several independent pieces of NOTIFICATION parameters if several problems exist or several
information must be transmitted. independent pieces of information must be transmitted.
To avoid certain types of attacks, a Responder SHOULD avoid sending a To avoid certain types of attacks, a Responder SHOULD avoid sending a
NOTIFICATION to any host with which it has not successfully verified NOTIFICATION to any host with which it has not successfully verified
a puzzle solution. a puzzle solution.
Notify Message Types in the range 0-16383 are intended for reporting Notify Message Types in the range 0-16383 are intended for reporting
errors and in the range 16384-65535 for other status information. An errors and in the range 16384-65535 for other status information. An
implementation that receives a NOTIFY packet with a Notify Message implementation that receives a NOTIFY packet with a Notify Message
Type that indicates an error in response to a request packet (e.g., Type that indicates an error in response to a request packet (e.g.,
I1, I2, UPDATE) SHOULD assume that the corresponding request has I1, I2, UPDATE) SHOULD assume that the corresponding request has
skipping to change at page 64, line 5 skipping to change at page 65, line 5
----------------------------- ----- ----------------------------- -----
I2_ACKNOWLEDGEMENT 16384 I2_ACKNOWLEDGEMENT 16384
The Responder has an I2 packet from the Initiator but had to The Responder has an I2 packet from the Initiator but had to
queue the I2 packet for processing. The puzzle was correctly queue the I2 packet for processing. The puzzle was correctly
solved and the Responder is willing to set up an association but solved and the Responder is willing to set up an association but
currently has a number of I2 packets in the processing queue. currently has a number of I2 packets in the processing queue.
The R2 packet is sent after the I2 packet was processed. The R2 packet is sent after the I2 packet was processed.
5.2.19. ECHO_REQUEST_SIGNED 5.2.20. ECHO_REQUEST_SIGNED
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) | | Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 897 Type 897
skipping to change at page 64, line 35 skipping to change at page 65, line 35
The ECHO_REQUEST_SIGNED and corresponding echo response parameters The ECHO_REQUEST_SIGNED and corresponding echo response parameters
MAY be used for any purpose where a node wants to carry some state in MAY be used for any purpose where a node wants to carry some state in
a request packet and get it back in a response packet. The a request packet and get it back in a response packet. The
ECHO_REQUEST_SIGNED is covered by the HIP_MAC and SIGNATURE. A HIP ECHO_REQUEST_SIGNED is covered by the HIP_MAC and SIGNATURE. A HIP
packet can contain only one ECHO_REQUEST_SIGNED parameter and MAY packet can contain only one ECHO_REQUEST_SIGNED parameter and MAY
contain multiple ECHO_REQUEST_UNSIGNED parameter. The contain multiple ECHO_REQUEST_UNSIGNED parameter. The
ECHO_REQUEST_SIGNED parameter MUST be responded to with an ECHO_REQUEST_SIGNED parameter MUST be responded to with an
ECHO_RESPONSE_SIGNED. ECHO_RESPONSE_SIGNED.
5.2.20. ECHO_REQUEST_UNSIGNED 5.2.21. ECHO_REQUEST_UNSIGNED
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) | | Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 63661 Type 63661
skipping to change at page 65, line 20 skipping to change at page 66, line 20
HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters.
It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters
in HIP packets passing by. The creator of the ECHO_REQUEST_UNSIGNED in HIP packets passing by. The creator of the ECHO_REQUEST_UNSIGNED
(end-host or middlebox) has to create the Opaque field so that it can (end-host or middlebox) has to create the Opaque field so that it can
later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED
parameter. parameter.
The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an
ECHO_RESPONSE_UNSIGNED parameter. ECHO_RESPONSE_UNSIGNED parameter.
5.2.21. ECHO_RESPONSE_SIGNED 5.2.22. ECHO_RESPONSE_SIGNED
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) | | Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 961 Type 961
skipping to change at page 66, line 5 skipping to change at page 67, line 5
The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data
that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back. that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back.
The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED
parameter. parameter.
The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be
used for any purpose where a node wants to carry some state in a used for any purpose where a node wants to carry some state in a
request packet and get it back in a response packet. The request packet and get it back in a response packet. The
ECHO_RESPONSE_SIGNED is covered by the HIP_MAC and SIGNATURE. ECHO_RESPONSE_SIGNED is covered by the HIP_MAC and SIGNATURE.
5.2.22. ECHO_RESPONSE_UNSIGNED 5.2.23. ECHO_RESPONSE_UNSIGNED
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) | | Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 63425 Type 63425
skipping to change at page 70, line 45 skipping to change at page 71, line 45
The HIT_SUITE_LIST parameter is an ordered list of the Responder's The HIT_SUITE_LIST parameter is an ordered list of the Responder's
preferred and supported HIT Suites. The list allows the Initiator to preferred and supported HIT Suites. The list allows the Initiator to
determine whether its own source HIT matches any suite supported by determine whether its own source HIT matches any suite supported by
the Responder. the Responder.
The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain
data that the sender wants to receive unmodified in the corresponding data that the sender wants to receive unmodified in the corresponding
response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED
parameter. The R1 packet may contain zero or more parameter. The R1 packet may contain zero or more
ECHO_REQUEST_UNSIGNED parameters as described in Section ECHO_REQUEST_UNSIGNED parameters as described in Section
Section 5.2.20. Section 5.2.21.
The signature is calculated over the whole HIP packet, after setting The signature is calculated over the whole HIP packet, after setting
the Initiator's HIT, header checksum, as well as the Opaque field and the Initiator's HIT, header checksum, as well as the Opaque field and
the Random #I in the PUZZLE parameter temporarily to zero, and the Random #I in the PUZZLE parameter temporarily to zero, and
excluding any parameters that follow the signature, as described in excluding any parameters that follow the signature, as described in
Section 5.2.14. This allows the Responder to use precomputed R1s. Section 5.2.15. This allows the Responder to use precomputed R1s.
The Initiator SHOULD validate this signature. It MUST check that the The Initiator SHOULD validate this signature. It MUST check that the
Responder's HI matches with the one expected, if any. Responder's HI matches with the one expected, if any.
5.3.3. I2 - the Second HIP Initiator Packet 5.3.3. I2 - the Second HIP Initiator Packet
The HIP header values for the I2 packet: The HIP header values for the I2 packet:
Header: Header:
Type = 3 Type = 3
skipping to change at page 72, line 14 skipping to change at page 73, line 14
The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the
unmodified Opaque data copied from the corresponding echo request unmodified Opaque data copied from the corresponding echo request
parameter(s). parameter(s).
The HMAC value in the HIP_MAC parameter is calculated over the whole The HMAC value in the HIP_MAC parameter is calculated over the whole
HIP packet, excluding any parameters after the HIP_MAC, as described HIP packet, excluding any parameters after the HIP_MAC, as described
in Section 6.4.1. The Responder MUST validate the HIP_MAC. in Section 6.4.1. The Responder MUST validate the HIP_MAC.
The signature is calculated over the whole HIP packet, excluding any The signature is calculated over the whole HIP packet, excluding any
parameters after the HIP_SIGNATURE, as described in Section 5.2.13. parameters after the HIP_SIGNATURE, as described in Section 5.2.14.
The Responder MUST validate this signature. The Responder uses the The Responder MUST validate this signature. The Responder uses the
HI in the packet or a HI acquired by some other means for verifying HI in the packet or a HI acquired by some other means for verifying
the signature. the signature.
5.3.4. R2 - the Second HIP Responder Packet 5.3.4. R2 - the Second HIP Responder Packet
The HIP header values for the R2 packet: The HIP header values for the R2 packet:
Header: Header:
Packet Type = 4 Packet Type = 4
skipping to change at page 73, line 16 skipping to change at page 74, line 16
Valid control bits: None Valid control bits: None
The UPDATE packet contains mandatory HIP_MAC and HIP_SIGNATURE The UPDATE packet contains mandatory HIP_MAC and HIP_SIGNATURE
parameters, and other optional parameters. parameters, and other optional parameters.
The UPDATE packet contains zero or one SEQ parameter. The presence The UPDATE packet contains zero or one SEQ parameter. The presence
of a SEQ parameter indicates that the receiver MUST acknowledge the of a SEQ parameter indicates that the receiver MUST acknowledge the
the UPDATE. An UPDATE that does not contain a SEQ but only an ACK the UPDATE. An UPDATE that does not contain a SEQ but only an ACK
parameter is simply an acknowledgment of a previous UPDATE and itself parameter is simply an acknowledgment of a previous UPDATE and itself
MUST NOT be acknowledged by a separate ACK. UPDATE packets without MUST NOT be acknowledged by a separate ACK. Such UPDATE packets
SEQ parameters do not require an acknowledgment and do not require containing only an ACK parameter do not require processing in
processing in relative order to other UPDATE packets. relative order to other UPDATE packets. An UPDATE packet without
either a SEQ or an ACK parameter is invalid; such unacknowledged
updates MUST instead use a NOTIFY packet.
An UPDATE packet contains zero or one ACK parameters. The ACK An UPDATE packet contains zero or one ACK parameters. The ACK
parameter echoes the SEQ sequence number of the UPDATE packet being parameter echoes the SEQ sequence number of the UPDATE packet being
ACKed. A host MAY choose to acknowledge more than one UPDATE packet ACKed. A host MAY choose to acknowledge more than one UPDATE packet
at a time; e.g., the ACK may contain the last two SEQ values at a time; e.g., the ACK may contain the last two SEQ values
received, for resilience against ACK loss. ACK values are not received, for resilience against ACK loss. ACK values are not
cumulative; each received unique SEQ value requires at least one cumulative; each received unique SEQ value requires at least one
corresponding ACK value in reply. Received ACKs that are redundant corresponding ACK value in reply. Received ACKs that are redundant
are ignored. Hosts MUST implement the processing of ACKs with are ignored. Hosts MUST implement the processing of ACKs with
multiple SEQ numbers even if they do not implement sending ACKs with multiple SEQ numbers even if they do not implement sending ACKs with
skipping to change at page 81, line 38 skipping to change at page 82, line 45
the beginning of the HIP_MAC_2 parameter and increased by the the beginning of the HIP_MAC_2 parameter and increased by the
length of the concatenated HOST_ID parameter length (including length of the concatenated HOST_ID parameter length (including
type and length fields). type and length fields).
o HOST_ID parameter is exactly in the form it was received in the R1 o HOST_ID parameter is exactly in the form it was received in the R1
packet from the Responder. packet from the Responder.
Parameter order is described in Section 5.2.1, except that the Parameter order is described in Section 5.2.1, except that the
HOST_ID parameter in this calculation is added to the end. HOST_ID parameter in this calculation is added to the end.
The HIP_MAC parameter is defined in Section 5.2.11 and the HIP_MAC_2 The HIP_MAC parameter is defined in Section 5.2.12 and the HIP_MAC_2
parameter in Section 5.2.12. The HMAC calculation and verification parameter in Section 5.2.13. The HMAC calculation and verification
process (the process applies both to HIP_MAC and HIP_MAC_2 except process (the process applies both to HIP_MAC and HIP_MAC_2 except
where HIP_MAC_2 is mentioned separately) is as follows: where HIP_MAC_2 is mentioned separately) is as follows:
Packet sender: Packet sender:
1. Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE, 1. Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE,
HIP_SIGNATURE_2, or any other parameter with greater Type value HIP_SIGNATURE_2, or any other parameter with greater Type value
than the HIP_MAC parameter has. than the HIP_MAC parameter has.
2. In case of HIP_MAC_2 calculation, add a HOST_ID (Responder) 2. In case of HIP_MAC_2 calculation, add a HOST_ID (Responder)
skipping to change at page 82, line 43 skipping to change at page 83, line 50
Responder. Responder.
4. Recalculate the HIP packet length in the HIP header and clear the 4. Recalculate the HIP packet length in the HIP header and clear the
Checksum field (set it to all zeros). In case of HIP_MAC_2, the Checksum field (set it to all zeros). In case of HIP_MAC_2, the
length is calculated with the added HOST_ID parameter. length is calculated with the added HOST_ID parameter.
5. Compute the HMAC using either HIP-gl or HIP-lg integrity key as 5. Compute the HMAC using either HIP-gl or HIP-lg integrity key as
defined in Section 6.5 and verify it against the received HMAC. defined in Section 6.5 and verify it against the received HMAC.
6. Set Checksum and Header Length field in the HIP header to 6. Set Checksum and Header Length field in the HIP header to
original values. original values. Note that the checksum and length fields
contain incorrect values after this step.
7. In case of HIP_MAC_2, remove the HOST_ID parameter from the 7. In case of HIP_MAC_2, remove the HOST_ID parameter from the
packet before further processing. packet before further processing.
6.4.2. Signature Calculation 6.4.2. Signature Calculation
The following process applies both to the HIP_SIGNATURE and The following process applies both to the HIP_SIGNATURE and
HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2, the HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2, the
only difference is that instead of the HIP_SIGNATURE parameter, the only difference is that instead of the HIP_SIGNATURE parameter, the
HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE
Opaque and Random #I fields are cleared (set to all zeros) before Opaque and Random #I fields are cleared (set to all zeros) before
computing the signature. The HIP_SIGNATURE parameter is defined in computing the signature. The HIP_SIGNATURE parameter is defined in
Section 5.2.13 and the HIP_SIGNATURE_2 parameter in Section 5.2.14. Section 5.2.14 and the HIP_SIGNATURE_2 parameter in Section 5.2.15.
The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2
is: is:
HIP_SIGNATURE: { HIP header | [ Parameters ] } HIP_SIGNATURE: { HIP header | [ Parameters ] }
where Parameters include all HIP parameters for the packet that is where Parameters include all HIP parameters for the packet that is
being calculated with Type values from 1 to (HIP_SIGNATURE's Type being calculated with Type values from 1 to (HIP_SIGNATURE's Type
value - 1). value - 1).
skipping to change at page 85, line 28 skipping to change at page 86, line 36
that were exchanged in R1 and I2 messages when this HIP association that were exchanged in R1 and I2 messages when this HIP association
was set up. Both hosts have to store #I and #J values for the HIP was set up. Both hosts have to store #I and #J values for the HIP
association for future use. association for future use.
The initial keys are drawn sequentially in the order that is The initial keys are drawn sequentially in the order that is
determined by the numeric comparison of the two HITs, with comparison determined by the numeric comparison of the two HITs, with comparison
method described in the previous paragraph. HOST_g denotes the host method described in the previous paragraph. HOST_g denotes the host
with the greater HIT value, and HOST_l the host with the lower HIT with the greater HIT value, and HOST_l the host with the lower HIT
value. value.
The drawing order for the initial keys is as follows: The drawing order for the four initial keys is as follows:
HIP-gl encryption key for HOST_g's ENCRYPTED parameter HIP-gl encryption key for HOST_g's ENCRYPTED parameter
HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets
HIP-lg encryption key for HOST_l's ENCRYPTED parameter HIP-lg encryption key for HOST_l's ENCRYPTED parameter
HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets
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
skipping to change at page 89, line 9 skipping to change at page 90, line 16
R1 packet, it creates a new R1 or selects a precomputed R1 R1 packet, it creates a new R1 or selects a precomputed R1
according to the format described in Section 5.3.2. It creates according to the format described in Section 5.3.2. It creates
or chooses an R1 that contains its most preferred DH public value or chooses an R1 that contains its most preferred DH public value
that is also contained in the DH_GROUP_LIST in the I1 packet. If that is also contained in the DH_GROUP_LIST in the I1 packet. If
no suitable DH Group ID was contained in the DH_GROUP_LIST in the no suitable DH Group ID was contained in the DH_GROUP_LIST in the
I1 packet, it sends an R1 with any suitable DH public key. I1 packet, it sends an R1 with any suitable DH public key.
5. If the received Responder's HIT in the I1 is NULL, the Responder 5. If the received Responder's HIT in the I1 is NULL, the Responder
selects a HIT with a the same HIT Suite as the Initiator's HIT. selects a HIT with a the same HIT Suite as the Initiator's HIT.
If this HIT Suite is not supported by the Responder, it SHOULD If this HIT Suite is not supported by the Responder, it SHOULD
select a REQUIRED HIT Suite from Section 5.2.9, which is select a REQUIRED HIT Suite from Section 5.2.10, which is
currently RSA/DSA/SHA-1. Other than that, selecting the HIT is a currently RSA/DSA/SHA-1. Other than that, selecting the HIT is a
local policy matter. local policy matter.
6. The Responder sends the R1 packet to the source IP address of the 6. The responder expresses its supported HIP transport formats in
the TRANSPORT_FORMAT_LIST as described in Section 5.2.10. The
Responder MUST at least provide one payload transport format
type.
7. The Responder sends the R1 packet to the source IP address of the
I1 packet. I1 packet.
6.7.1. R1 Management 6.7.1. R1 Management
All compliant implementations MUST be able to produce R1 packets. An All compliant implementations MUST be able to produce R1 packets. An
R1 packet MAY be precomputed. An R1 packet MAY be reused for time R1 packet MAY be precomputed. An R1 packet MAY be reused for time
Delta T, which is implementation dependent, and SHOULD be deprecated Delta T, which is implementation dependent, and SHOULD be deprecated
and not used once a valid response I2 packet has been received from and not used once a valid response I2 packet has been received from
an Initiator. During an I1 message storm, an R1 packet MAY be re- an Initiator. During an I1 message storm, an R1 packet MAY be re-
used beyond this limit. R1 information MUST NOT be discarded until used beyond this limit. R1 information MUST NOT be discarded until
skipping to change at page 90, line 20 skipping to change at page 91, line 31
among the set with the largest R1 generation counter. among the set with the largest R1 generation counter.
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 packet to the originator of the R1 packet (i.e., it has a an I1 packet to the originator of the R1 packet (i.e., it has a
HIP association that is in state I1-SENT and that is associated HIP association that is in state I1-SENT and that is associated
with the HITs in the R1). Unless the I1 packet was sent in with the HITs in the R1). Unless the I1 packet was sent in
opportunistic mode (see Section 4.1.8), the IP addresses in the opportunistic mode (see Section 4.1.8), the IP addresses in the
received R1 packet SHOULD be ignored and, when looking up the received R1 packet SHOULD be ignored by the R1 processing and,
right HIP association, the received R1 packet SHOULD be matched when looking up the right HIP association, the received R1
against the associations using only the HITs. If a match packet SHOULD be matched against the associations using only the
exists, the system should process the R1 packet as described HITs. If a match exists, the system should process the R1
below. packet as described below.
2. Otherwise, if the system is in any other state than I1-SENT or 2. Otherwise, if the system is in any other state than I1-SENT or
I2-SENT with respect to the HITs included in the R1 packet, it I2-SENT with respect to the HITs included in the R1 packet, it
SHOULD silently drop the R1 packet and remain in the current SHOULD silently drop the R1 packet and remain in the current
state. state.
3. If the HIP association state is I1-SENT or I2-SENT, the received 3. If the HIP association state is I1-SENT or I2-SENT, the received
Initiator's HIT MUST correspond to the HIT used in the original Initiator's HIT MUST correspond to the HIT used in the original
I1. Also, the Responder's HIT MUST correspond to the one used I1. Also, the Responder's HIT MUST correspond to the one used
in the I1, unless the I1 packet contained a NULL HIT. in the I1, unless the I1 packet contained a NULL HIT.
4. 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 5.2.14. further packet processing, according to Section 5.2.15.
5. If the HIP association state is I1-SENT, and multiple valid R1 5. If the HIP association state is I1-SENT, and multiple valid R1
packets are present, the system MUST select from among the R1 packets are present, the system MUST select from among the R1
packets with the largest R1 generation counter. packets with the largest R1 generation counter.
6. The system MUST check that the Initiator HIT Suite is contained 6. The system MUST check that the Initiator HIT Suite is contained
in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the
Initiator's HIT Suite is supported by the Responder). If the Initiator's HIT Suite is supported by the Responder). If the
HIT Suite is supported by the Responder, the system proceeds HIT Suite is supported by the Responder, the system proceeds
normally. Otherwise, the system MAY stay in state I1-sent and normally. Otherwise, the system MAY stay in state I1-sent and
skipping to change at page 92, line 9 skipping to change at page 93, line 18
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 6.5. Kij is used for key extraction as specified in Section 6.5.
14. The system selects the HIP_CIPHER ID from the choices presented 14. The system selects the HIP_CIPHER ID from the choices presented
in the R1 packet and uses the selected values subsequently when in the R1 packet and uses the selected values subsequently when
generating and using encryption keys, and when sending the I2 generating and using encryption keys, and when sending the I2
packet. If the proposed alternatives are not acceptable to the packet. If the proposed alternatives are not acceptable to the
system, it may either resend an I1 within the retry bounds or system, it may either resend an I1 within the retry bounds or
abandon the HIP base exchange. abandon the HIP base exchange.
15. The system initializes the remaining variables in the associated 15. The system chooses one suitable transport format from the
TRANSPORT_FORMAT_LIST and includes the respective transport
format parameter in the subsequent I2 packet.
16. The system initializes the remaining variables in the associated
state, including Update ID counters. state, including Update ID counters.
16. The system prepares and sends an I2 packet, as described in 17. The system prepares and sends an I2 packet, as described in
Section 5.3.3. Section 5.3.3.
17. The system SHOULD start a timer whose timeout value SHOULD be 18. 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 packet. The sender timeout counter associated with the I2 packet. The sender
SHOULD retransmit the I2 packet upon a timeout and restart the SHOULD retransmit the I2 packet upon a timeout and restart the
timer, up to a maximum of I2_RETRIES_MAX tries. timer, up to a maximum of I2_RETRIES_MAX tries.
18. If the system is in state I1-SENT, it SHALL transition to state 19. If the system is in state I1-SENT, it SHALL transition to state
I2-SENT. If the system is in any other state, it remains in the I2-SENT. If the system is in any other state, it remains in the
current state. current state.
6.8.1. Handling of Malformed Messages 6.8.1. Handling of Malformed Messages
If an implementation receives a malformed R1 message, it MUST If an implementation receives a malformed R1 message, it MUST
silently drop the packet. Sending a NOTIFY or ICMP would not help, silently drop the packet. Sending a NOTIFY or ICMP would not help,
as the sender of the R1 packet typically doesn't have any state. An as the sender of the R1 packet typically doesn't have any state. An
implementation SHOULD wait for some more time for a possibly well- implementation SHOULD wait for some more time for a possibly well-
formed R1, after which it MAY try again by sending a new I1 packet. formed R1, after which it MAY try again by sending a new I1 packet.
skipping to change at page 94, line 29 skipping to change at page 95, line 42
11. The encrypted HOST_ID is decrypted by the Initiator's encryption 11. The encrypted HOST_ID is decrypted by the Initiator's encryption
key defined in Section 6.5. If the decrypted data is not a key defined in Section 6.5. If the decrypted data is not a
HOST_ID parameter, the I2 packet is silently dropped. HOST_ID parameter, the I2 packet is silently dropped.
12. The implementation SHOULD also verify that the Initiator's HIT 12. The implementation SHOULD also verify that the Initiator's HIT
in the I2 packet corresponds to the Host Identity sent in the I2 in the I2 packet corresponds to the Host Identity sent in the I2
packet. (Note: some middleboxes may not able to make this packet. (Note: some middleboxes may not able to make this
verification.) verification.)
13. The system MUST verify the HIP_MAC according to the procedures 13. The system MUST verify the HIP_MAC according to the procedures
in Section 5.2.11. in Section 5.2.12.
14. The system MUST verify the HIP_SIGNATURE according to 14. The system MUST verify the HIP_SIGNATURE according to
Section 5.2.13 and Section 5.3.3. Section 5.2.14 and Section 5.3.3.
15. If the checks above are valid, then the system proceeds with 15. If the checks above are valid, then the system proceeds with
further I2 processing; otherwise, it discards the I2 and its further I2 processing; otherwise, it discards the I2 and its
state machine remains in the same state. state machine remains in the same state.
16. The I2 packet may have the A bit set -- in this case, the system 16. The I2 packet may have the A bit set -- in this case, the system
MAY choose to refuse it by dropping the I2 and the state machine MAY choose to refuse it by dropping the I2 and the state machine
returns to state UNASSOCIATED. If the A bit is set, the returns to state UNASSOCIATED. If the A bit is set, the
Initiator's HIT is anonymous and should not be stored Initiator's HIT is anonymous and should not be stored
permanently. permanently.
skipping to change at page 95, line 46 skipping to change at page 97, line 13
incoming R2 packet: incoming R2 packet:
1. If the system is in any other state than I2-SENT, the R2 packet 1. If the system is in any other state than I2-SENT, the R2 packet
is silently dropped. is silently dropped.
2. The system MUST verify that the HITs in use correspond to the 2. The system MUST verify that the HITs in use correspond to the
HITs that were received in the R1 packet that caused the HITs that were received in the R1 packet that caused the
transition to the I1-SENT state. transition to the I1-SENT state.
3. The system MUST verify the HIP_MAC_2 according to the procedures 3. The system MUST verify the HIP_MAC_2 according to the procedures
in Section 5.2.12. in Section 5.2.13.
4. The system MUST verify the HIP signature according to the 4. The system MUST verify the HIP signature according to the
procedures in Section 5.2.13. procedures in Section 5.2.14.
5. If any of the checks above fail, there is a high probability of 5. 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.
6. Upon successful processing of the R2 packet, the state machine 6. Upon successful processing of the R2 packet, the state machine
transitions to state ESTABLISHED. transitions to state ESTABLISHED.
6.11. Sending UPDATE Packets 6.11. Sending UPDATE Packets
skipping to change at page 99, line 47 skipping to change at page 101, line 16
packets triggers creating and establishing of a new HIP association, packets triggers creating and establishing of a new HIP association,
starting with sending of an I1 packet. starting with sending of an I1 packet.
If there is no corresponding HIP association, the CLOSE packet is If there is no corresponding HIP association, the CLOSE packet is
dropped. dropped.
6.15. Processing CLOSE_ACK Packets 6.15. Processing CLOSE_ACK Packets
When a host receives a CLOSE_ACK message, it verifies that it is in When a host receives a CLOSE_ACK message, it verifies that it is in
CLOSING or CLOSED state and that the CLOSE_ACK was in response to the CLOSING or CLOSED state and that the CLOSE_ACK was in response to the
CLOSE. A host can map CLOSE messages to CLOSE_ACK messages by using CLOSE. A host can map CLOSE_ACK messages to CLOSE messages by
the included ECHO_RESPONSE_SIGNED that was sent in the CLOSE_ACK comparing the value of ECHO_REQUEST_SIGNED (in the CLOSE packet) to
packet in response to the ECHO_REQUEST_SIGNED in the CLOSE packet. the value of ECHO_RESPONSE_SIGNED (in the CLOSE_ACK packet).
The CLOSE_ACK contains the HIP_MAC and the SIGNATURE parameters for The CLOSE_ACK contains the HIP_MAC and the SIGNATURE parameters for
verification. The state is discarded when the state changes to verification. The state is discarded when the state changes to
UNASSOCIATED and, after that, the host MAY respond with an ICMP UNASSOCIATED and, after that, the host MAY respond with an ICMP
Parameter Problem to an incoming CLOSE message (see Section 5.4.4). Parameter Problem to an incoming CLOSE message (see Section 5.4.4).
6.16. Handling State Loss 6.16. Handling State Loss
In the case of a system crash and unanticipated state loss, the In the case of a system crash and unanticipated state loss, the
system SHOULD delete the corresponding HIP state, including the system SHOULD delete the corresponding HIP state, including the
skipping to change at page 100, line 29 skipping to change at page 101, line 47
7. HIP Policies 7. HIP Policies
There are a number of variables that will influence the HIP base There are a number of variables that will influence the HIP base
exchanges that each host must support. All HIP implementations MUST exchanges that each host must support. All HIP implementations MUST
support more than one simultaneous HI, at least one of which SHOULD support more than one simultaneous HI, at least one of which SHOULD
be reserved for anonymous usage. Although anonymous HIs will be be reserved for anonymous usage. Although anonymous HIs will be
rarely used as Responders' HIs, they will be common for Initiators. rarely used as Responders' HIs, they will be common for Initiators.
Support for more than two HIs is RECOMMENDED. Support for more than two HIs is RECOMMENDED.
Initiators MAY use a different HI for different Responders to provide Initiators MAY use a different HI for different Responders to provide
basic privacy. Whether such private HITs are used repeatedly with basic privacy. Whether such private HIs are used repeatedly with the
the same Responder and how long these HITs are used is decided by same Responder and how long these HIs are used is decided by local
local policy and depends on the privacy requirements of the policy and depends on the privacy requirements of the Initiator.
Initiator.
The value of #K used in the HIP R1 must be chosen with care. Too The value of #K used in the HIP R1 must be chosen with care. Too
high numbers of #K will exclude clients with weak CPUs because these high numbers of #K will exclude clients with weak CPUs because these
devices cannot solve the puzzle within reasonable time. #K should devices cannot solve the puzzle within reasonable time. #K should
only be raised if a Responder is under high load, i.e., it cannot only be raised if a Responder is under high load, i.e., it cannot
process all incoming HIP handshakes any more. If a responder is not process all incoming HIP handshakes any more. If a responder is not
under high load, K SHOULD be 0. under high load, K SHOULD be 0.
Responders that only respond to selected Initiators require an ACL, Responders that only respond to selected Initiators require an ACL,
representing for which hosts they accept HIP base exchanges, and the representing for which hosts they accept HIP base exchanges, and the
skipping to change at page 104, line 35 skipping to change at page 105, line 51
At the time being, the HIT Suite uses only four bits because these At the time being, the HIT Suite uses only four bits because these
bits have to be carried in the HIT. Using more bits for the HIT bits have to be carried in the HIT. Using more bits for the HIT
Suite ID reduces the cryptographic strength of the HIT. HIT Suite Suite ID reduces the cryptographic strength of the HIT. HIT Suite
IDs must be allocated carefully to avoid namespace exhaustion. IDs must be allocated carefully to avoid namespace exhaustion.
Moreover, deprecated IDs should be reused after an appropriate Moreover, deprecated IDs should be reused after an appropriate
time span. If 16 Suite IDs prove insufficient and more HIT Suite time span. If 16 Suite IDs prove insufficient and more HIT Suite
IDs are needed concurrently, more bits can be used for the HIT IDs are needed concurrently, more bits can be used for the HIT
Suite ID by using one HIT Suite ID (0) to indicate that more bits Suite ID by using one HIT Suite ID (0) to indicate that more bits
should be used. The HIT_SUITE_LIST parameter already supports should be used. The HIT_SUITE_LIST parameter already supports
8-bit HIT Suite IDs, should longer IDs be needed. Possible 8-bit HIT Suite IDs, should longer IDs be needed. Possible
extensions of the HIT Suite ID space to accomodate eight bits and extensions of the HIT Suite ID space to accommodate eight bits and
new HIT Suite IDs are defined through IETF Review. new HIT Suite IDs are defined through IETF Review or IESG
Approval.
Parameter Type Parameter Type
The 16-bit Type field in a HIP parameter describes the type of the The 16-bit Type field in a HIP parameter describes the type of the
parameter. It is defined in Section 5.2.1. The current values parameter. It is defined in Section 5.2.1. The current values
are defined in Sections 5.2.3 through 5.2.22. are defined in Sections 5.2.3 through 5.2.23.
With the exception of the assigned Type codes, the Type codes 0 With the exception of the assigned Type codes, the Type codes 0
through 1023 and 61440 through 65535 are reserved for future base through 1023 and 61440 through 65535 are reserved for future base
protocol extensions, and are assigned through IETF Review. protocol extensions, and are assigned through IETF Review or IESG
Approval.
The Type codes 32768 through 49151 are reserved for The Type codes 32768 through 49151 are reserved for
experimentation. Types SHOULD be selected in a random fashion experimentation. Types SHOULD be selected in a random fashion
from this range, thereby reducing the probability of collisions. from this range, thereby reducing the probability of collisions.
A method employing genuine randomness (such as flipping a coin) A method employing genuine randomness (such as flipping a coin)
SHOULD be used. SHOULD be used.
All other Type codes are assigned through First Come First Served, All other Type codes are assigned through First Come First Served,
with Specification Required [RFC5226]. with Specification Required [RFC5226].
Group ID Group ID
The eight-bit Group ID values appear in the DIFFIE_HELLMAN The eight-bit Group ID values appear in the DIFFIE_HELLMAN
parameter and the DH_GROUP_LIST parameter and are defined in parameter and the DH_GROUP_LIST parameter and are defined in
Section 5.2.6. New values are assigned through IETF Review. Section 5.2.7. New values are assigned through IETF Review or
IESG Approval.
HIP Cipher ID HIP Cipher ID
The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined
in Section 5.2.7. New values either from the reserved or in Section 5.2.8. New values either from the reserved or
unassigned space are assigned through IETF Review. unassigned space are assigned through IETF Review or IESG
Approval.
DI-Type DI-Type
The four-bit DI-Type values in a HOST_ID parameter are defined in The four-bit DI-Type values in a HOST_ID parameter are defined in
Section 5.2.8. New values are assigned through IETF Review. Section 5.2.9. New values are assigned through IETF Review or
IESG Approval.
Notify Message Type Notify Message Type
The 16-bit Notify Message Type values in a NOTIFICATION parameter The 16-bit Notify Message Type values in a NOTIFICATION parameter
are defined in Section 5.2.18. are defined in Section 5.2.19.
Notify Message Type values 1-10 are used for informing about Notify Message Type values 1-10 are used for informing about
errors in packet structures, values 11-20 for informing about errors in packet structures, values 11-20 for informing about
problems in parameters containing cryptographic related material, problems in parameters containing cryptographic related material,
values 21-30 for informing about problems in authentication or values 21-30 for informing about problems in authentication or
packet integrity verification. Parameter numbers above 30 can be packet integrity verification. Parameter numbers above 30 can be
used for informing about other types of errors or events. Values used for informing about other types of errors or events. Values
51-8191 are error types reserved to be allocated by IANA. Values 51-8191 are error types reserved to be allocated by IANA. Values
8192-16383 are error types for experimentation. Values 16385- 8192-16383 are error types for experimentation. Values 16385-
40959 are status types to be allocated by IANA, and values 40960- 40959 are status types to be allocated by IANA, and values 40960-
skipping to change at page 106, line 45 skipping to change at page 108, line 18
changes were introduced through the working group process. Most changes were introduced through the working group process. Most
notably, the original document was split in two, one containing the notably, the original document was split in two, one containing the
base exchange and the other one defining how to use ESP. Some base exchange and the other one defining how to use ESP. Some
modifications to the protocol proposed by Aura, et al., [AUR03] were modifications to the protocol proposed by Aura, et al., [AUR03] were
added at a later stage. added at a later stage.
11. Changes from RFC 5201 11. Changes from RFC 5201
This section summarizes the changes made from [RFC5201]. This section summarizes the changes made from [RFC5201].
11.1. Changes from draft-ietf-hip-rfc5201-bis-04 11.1. Changes from draft-ietf-hip-rfc5201-bis-05
o Moved this list farther to the back. o Changed type number of DH_GROUP_LIST from 2151 to 511 because it
was in the number space that is reserved for the HIP transport
mode negotiations.
o Added transport form type list parameter. Transport forms are now
negotiated with this list instead of by their order in the HIP
packet. This allows to remove the exception of the transport
format parameters that were ordered by their preference instead of
by their type number. This should remove complexity from
implementations.
o Clarify that in HIP signature processing, the restored checksum
and length fields have been rendered invalid by the previous
steps.
o Clarify behavior for when UPDATE does not contain SEQ or ACQ
(disallow this).
o For namespace changes, changed "IETF Review" to "IETF Review or
IESG Approval".
o Addressed IESG comment about ignoring packet IP addresses.
o Permit using Anonymous HI control in packets other than R1/I2.
o Fixed minor reference error (RFC2418, RFC2410).
o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable
via the UI.
o Editorial changes.
11.2. Changes from draft-ietf-hip-rfc5201-bis-04
o Clarifications of the Security Considerations section. One DoS o Clarifications of the Security Considerations section. One DoS
defense mechanism was changed to be more effective and less prone defense mechanism was changed to be more effective and less prone
to misuse. to misuse.
o Minor clarifications of the state machine. o Minor clarifications of the state machine.
o Clarified text on HIP puzzle. o Clarified text on HIP puzzle.
o Added names and references for figures. o Added names and references for figures.
skipping to change at page 107, line 51 skipping to change at page 110, line 10
contains ONE update ID. ACK may acknowledge SEVERAL update IDs. contains ONE update ID. ACK may acknowledge SEVERAL update IDs.
o Added wording that several NOTIFY parameters may be present in a o Added wording that several NOTIFY parameters may be present in a
HIP packet. HIP packet.
o Changed wording for the ECHO_RESPONSE_SIGNED parameter. Also o Changed wording for the ECHO_RESPONSE_SIGNED parameter. Also
lifted the restriction that only one ECHO_RESPONSE_UNSIGNED lifted the restriction that only one ECHO_RESPONSE_UNSIGNED
parameter MUST be present in each HIP control packet. This did parameter MUST be present in each HIP control packet. This did
contradict the definition of the ECHO_RESPONSE_UNSIGNED parameter. contradict the definition of the ECHO_RESPONSE_UNSIGNED parameter.
o Changed IETF Consensus to IETF Review in IANA section. o Changed IETF Consensus to IETF Review or IESG Approval in IANA
section.
o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K
throughout the document. throughout the document.
o Updated references. o Updated references.
o Editorial changes. o Editorial changes.
11.2. Changes from draft-ietf-hip-rfc5201-bis-03 11.3. Changes from draft-ietf-hip-rfc5201-bis-03
o Editorial changes to improve clarity and readability. o Editorial changes to improve clarity and readability.
o Removed obsoleted (not applicable) attack from security o Removed obsoleted (not applicable) attack from security
consideration section. consideration section.
o Added a requirement that hosts MUST support processing of ACK o Added a requirement that hosts MUST support processing of ACK
parameters with several SEQ numbers even when they do not support parameters with several SEQ numbers even when they do not support
sending such parameters. sending such parameters.
skipping to change at page 108, line 48 skipping to change at page 111, line 7
o Clarified the use of HITs in opportunistic mode. o Clarified the use of HITs in opportunistic mode.
o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as
between SIGNATURE and SIGNATURE_2. between SIGNATURE and SIGNATURE_2.
o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to
RESPONDER_BUSY_PLEASE_RETRY. RESPONDER_BUSY_PLEASE_RETRY.
o Mentioned that there are multiple valid puzzle solutions. o Mentioned that there are multiple valid puzzle solutions.
11.3. Changes from draft-ietf-hip-rfc5201-bis-02 11.4. Changes from draft-ietf-hip-rfc5201-bis-02
o Added recommendation to not use puzzle #I twice for the same host o Added recommendation to not use puzzle #I twice for the same host
to avoid identical key material. to avoid identical key material.
o Revised state machine and added missing event handling. o Revised state machine and added missing event handling.
o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT
suites. suites.
o Revised parameter type numbers (corresponding to IANA allocations) o Revised parameter type numbers (corresponding to IANA allocations)
and added missing "free for experimentation" range to the and added missing "free for experimentation" range to the
description. description.
o Clarifying note on the use of the C bit in the parameter type o Clarifying note on the use of the C bit in the parameter type
numbers. numbers.
11.4. Changes from draft-ietf-hip-rfc5201-bis-01 11.5. Changes from draft-ietf-hip-rfc5201-bis-01
o Changed RHASH-len to RHASH_len to avoid confusion in calculations o Changed RHASH-len to RHASH_len to avoid confusion in calculations
(- could be minus) (- could be minus)
o Added RHASH_len to list of abbreviations o Added RHASH_len to list of abbreviations
o Fixed length of puzzle #I and #J to be 1*RHASH_len o Fixed length of puzzle #I and #J to be 1*RHASH_len
o Changed RHASH-len to RHASH_len to avoid confusion in calculations o Changed RHASH-len to RHASH_len to avoid confusion in calculations
(- could be minus) (- could be minus)
skipping to change at page 111, line 11 skipping to change at page 113, line 19
o Added text about new ORCHID structure to HIT overview. o Added text about new ORCHID structure to HIT overview.
o Moved Editor role to Robert Moskowitz. o Moved Editor role to Robert Moskowitz.
o Added SHA-256 to puzzle parameter. o Added SHA-256 to puzzle parameter.
o Generalized LTRUNC to be hash-function agnostic. o Generalized LTRUNC to be hash-function agnostic.
o Added text about RHASH depending on OGA. o Added text about RHASH depending on OGA.
11.5. Changes from draft-ietf-hip-rfc5201-bis-00 11.6. Changes from draft-ietf-hip-rfc5201-bis-00
o Added reasoning why BIS document is needed. o Added reasoning why BIS document is needed.
11.6. Contents of draft-ietf-hip-rfc5201-bis-00 11.7. Contents of draft-ietf-hip-rfc5201-bis-00
o RFC5201 was submitted as draft-RFC. o RFC5201 was submitted as draft-RFC.
12. References 12. References
12.1. Normative References 12.1. Normative References
[FIPS.180-2.2002] National Institute of Standards and [FIPS.180-2.2002] National Institute of Standards and
Technology, "Secure Hash Standard", Technology, "Secure Hash Standard",
FIPS PUB 180-2, August 2002, <http:// FIPS PUB 180-2, August 2002, <http://
 End of changes. 87 change blocks. 
304 lines changed or deleted 411 lines changed or added

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