draft-ietf-hip-rfc5201-bis-17.txt   draft-ietf-hip-rfc5201-bis-18.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 Hirschmann Automation and Control Intended status: Standards Track Hirschmann Automation and Control
Expires: March 9, 2015 P. Jokela Expires: March 26, 2015 P. Jokela
Ericsson Research NomadicLab Ericsson Research NomadicLab
T. Henderson T. Henderson
University of Washington University of Washington
September 5, 2014 September 22, 2014
Host Identity Protocol Version 2 (HIPv2) Host Identity Protocol Version 2 (HIPv2)
draft-ietf-hip-rfc5201-bis-17 draft-ietf-hip-rfc5201-bis-18
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 Diffie- communications across IP address changes. HIP is based on a Diffie-
Hellman key exchange, using public key identifiers from a new Host Hellman key exchange, using public key identifiers from a new Host
Identity namespace for mutual peer authentication. The protocol is Identity namespace for mutual peer authentication. The protocol is
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on March 9, 2015. This Internet-Draft will expire on March 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 29 skipping to change at page 3, line 29
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. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 49 5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 49
5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 51 5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 51
5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 52 5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 52
5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 53 5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 55 5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 55
5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 56 5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 56
5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 57 5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 57 5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 58
5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 58 5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 59
5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 59 5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 60
5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 60 5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 61
5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 62 5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 63
5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 65 5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 66
5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 66 5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 67
5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 66 5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 67
5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 67 5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 68
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 68 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 69
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 69 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 70
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 69 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 70
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 72 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 73
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 74 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 75
5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 74 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 75
5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 75 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 76
5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 76 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 77
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 76 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 77
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 77 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 78
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 77 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 78
5.4.2. Other Problems with the HIP Header and Packet 5.4.2. Other Problems with the HIP Header and Packet
Structure . . . . . . . . . . . . . . . . . . . . . . 77 Structure . . . . . . . . . . . . . . . . . . . . . . 78
5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 77 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 78
5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 78 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 79
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 78 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 79
6.1. Processing Outgoing Application Data . . . . . . . . . . 78 6.1. Processing Outgoing Application Data . . . . . . . . . . 79
6.2. Processing Incoming Application Data . . . . . . . . . . 79 6.2. Processing Incoming Application Data . . . . . . . . . . 80
6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 80 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 81
6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 82 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 83
6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 82 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 83
6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 84 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 85
6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 86 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 87
6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 88 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 89
6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 89 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 90
6.6.2. Processing Incoming ICMP Protocol Unreachable 6.6.2. Processing Incoming ICMP Protocol Unreachable
Messages . . . . . . . . . . . . . . . . . . . . . . 89 Messages . . . . . . . . . . . . . . . . . . . . . . 90
6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 90 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 91
6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 91 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 92
6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 91 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 92
6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 92 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 93
6.8.1. Handling of Malformed Messages . . . . . . . . . . . 94 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 95
6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 94 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 95
6.9.1. Handling of Malformed Messages . . . . . . . . . . . 97 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 98
6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 98 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 99
6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 98 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 99
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 99 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 100
6.12.1. Handling a SEQ Parameter in a Received UPDATE 6.12.1. Handling a SEQ Parameter in a Received UPDATE
Message . . . . . . . . . . . . . . . . . . . . . . 100 Message . . . . . . . . . . . . . . . . . . . . . . 101
6.12.2. Handling an ACK Parameter in a Received UPDATE 6.12.2. Handling an ACK Parameter in a Received UPDATE
Packet . . . . . . . . . . . . . . . . . . . . . . . 101 Packet . . . . . . . . . . . . . . . . . . . . . . . 102
6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 101 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 102
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 102 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 103
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 102 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 103
6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 102 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 103
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 103 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 104
8. Security Considerations . . . . . . . . . . . . . . . . . . . 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 104
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 110 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 111
11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 111 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 112
11.1. Changes from draft-ietf-hip-rfc5201-bis-16 . . . . . . . 111 11.1. Changes from draft-ietf-hip-rfc5201-bis-17 . . . . . . . 112
11.2. Changes from draft-ietf-hip-rfc5201-bis-15 . . . . . . . 111 11.2. Changes from draft-ietf-hip-rfc5201-bis-16 . . . . . . . 112
11.3. Changes from draft-ietf-hip-rfc5201-bis-14 . . . . . . . 111 11.3. Changes from draft-ietf-hip-rfc5201-bis-15 . . . . . . . 113
11.4. Changes from draft-ietf-hip-rfc5201-bis-13 . . . . . . . 112 11.4. Changes from draft-ietf-hip-rfc5201-bis-14 . . . . . . . 113
11.5. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 112 11.5. Changes from draft-ietf-hip-rfc5201-bis-13 . . . . . . . 113
11.6. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 112 11.6. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 113
11.7. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 112 11.7. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 113
11.8. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 112 11.8. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 113
11.9. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 112 11.9. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 113
11.10. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 112 11.10. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 113
11.11. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 112 11.11. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 114
11.12. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 113 11.12. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 114
11.13. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 113 11.13. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 114
11.14. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 115 11.14. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 115
11.15. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 115 11.15. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 116
11.16. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 116 11.16. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 117
11.17. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 118 11.17. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 117
11.18. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 118 11.18. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 119
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 118 11.19. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 119
12.1. Normative References . . . . . . . . . . . . . . . . . . 118 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 119
12.2. Informative References . . . . . . . . . . . . . . . . . 120 12.1. Normative References . . . . . . . . . . . . . . . . . . 119
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 123 12.2. Informative References . . . . . . . . . . . . . . . . . 121
Appendix B. Generating a Public Key Encoding from an HI . . 124 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 124
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 124 Appendix B. Generating a Public Key Encoding from an HI . . 125
C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 125 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 125
C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 125 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 126
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 126 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 126
Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 126 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 127
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 126 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 127
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 127
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 10, line 21 skipping to change at page 10, line 21
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
properties of the HIT see [I-D.ietf-hip-rfc4423-bis]. properties of the HIT see [I-D.ietf-hip-rfc4423-bis].
The structure of the HIT is defined in [I-D.ietf-hip-rfc4843-bis]. The structure of the HIT is defined in [RFC7343]. The HIT is an
The HIT is an Overlay Routable Cryptographic Hash Identifier (ORCHID) Overlay Routable Cryptographic Hash Identifier (ORCHID) and consists
and consists of three parts: first, an IANA assigned prefix to of three parts: first, an IANA assigned prefix to distinguish it from
distinguish it from other IPv6 addresses. Second, a four-bit other IPv6 addresses. Second, a four-bit encoding of the algorithms
encoding of the algorithms that were used for generating the HI and that were used for generating the HI and the hashed representation of
the hashed representation of HI. Third, a 96-bit hashed HI. Third, a 96-bit hashed representation of the Host Identity. The
representation of the Host Identity. The encoding of the ORCHID encoding of the ORCHID generation algorithm and the exact algorithm
generation algorithm and the exact algorithm for generating the for generating the hashed representation is specified in Appendix E.
hashed representation is specified in Appendix E.
Carrying HIs and HITs in the header of user data packets would Carrying HIs and HITs in the header of user data packets would
increase the overhead of packets. Thus, it is not expected that they increase the overhead of packets. Thus, it is not expected that they
are carried in every packet, but other methods are used to map the are carried in every packet, but other methods are used to map the
data packets to the corresponding HIs. In some cases, this makes it data packets to the corresponding HIs. In some cases, this makes it
possible to use HIP without any additional headers in the user data possible to use HIP without any additional headers in the user data
packets. For example, if ESP is used to protect data traffic, the packets. For example, if ESP is used to protect data traffic, the
Security Parameter Index (SPI) carried in the ESP header can be used Security Parameter Index (SPI) carried in the ESP header can be used
to map the encrypted data packet to the correct HIP association. to map the encrypted data packet to the correct HIP association.
3.1. Host Identity Tag (HIT) 3.1. Host Identity Tag (HIT)
The Host Identity Tag is a 128-bit value -- a hashed encoding of the The Host Identity Tag is a 128-bit value -- a hashed encoding of the
Host Identifier. There are two advantages of using a hashed encoding Host Identifier. There are two advantages of using a hashed encoding
over the actual variable-sized Host Identity public key in protocols. over the actual variable-sized Host Identity public key in protocols.
First, the fixed length of the HIT keeps packet sizes manageable and First, the fixed length of the HIT keeps packet sizes manageable and
eases protocol coding. Second, it presents a consistent format for eases protocol coding. Second, it presents a consistent format for
the protocol, independent of the underlying identity technology in the protocol, independent of the underlying identity technology in
use. use.
RFC 4843-bis [I-D.ietf-hip-rfc4843-bis] specifies 128-bit hash-based RFC 7343 [RFC7343] specifies 128-bit hash-based identifiers, called
identifiers, called Overlay Routable Cryptographic Hash Identifiers, Overlay Routable Cryptographic Hash Identifiers, ORCHIDs. Their
ORCHIDs. Their prefix, allocated from the IPv6 address block, is prefix, allocated from the IPv6 address block, is defined in
defined in [I-D.ietf-hip-rfc4843-bis]. The Host Identity Tag is one [RFC7343]. The Host Identity Tag is one type of an ORCHID.
type of an ORCHID.
This document extends the original, experimental HIP specification This document extends the original, experimental HIP specification
[RFC5201] with measures to support crypto agility. One of these [RFC5201] with measures to support crypto agility. One of these
measures is to allow different hash functions for creating a HIT. measures is to allow different hash functions for creating a HIT.
HIT Suites group the sets of algorithms that are required to generate HIT Suites group the sets of algorithms that are required to generate
and use a particular HIT. The Suites are encoded in HIT Suite IDs. and use a particular HIT. The Suites are encoded in HIT Suite IDs.
These HIT Suite IDs are transmitted in the ORCHID Generation These HIT Suite IDs are transmitted in the ORCHID Generation
Algorithm (OGA) field in the ORCHID. With the HIT Suite ID in the Algorithm (OGA) field in the ORCHID. With the HIT Suite ID in the
OGA field, a host can tell from another host's HIT, whether it OGA field, a host 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 [RFC7343] using a context ID value of 0xF0EF F02F BFF4
0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been 3D0F E793 0C3C 6E61 74EA (this tag value has been generated randomly
generated randomly by the editor of this specification), and an input by the editor of this specification), and an input that encodes the
that encodes the Host Identity field (see Section 5.2.9) present in a Host Identity field (see Section 5.2.9) present in a HIP payload
HIP payload packet. The set of hash function, signature algorithm, packet. The set of hash function, signature algorithm, and the
and the algorithm used for generating the HIT from the HI depends on algorithm used for generating the HIT from the HI depends on the HIT
the HIT Suite (see Appendix E) and is indicated by the four bits of Suite (see Appendix E) and is indicated by the four bits of the
the ORCHID Generation Algorithm (OGA) field in the ORCHID. ORCHID Generation Algorithm (OGA) field in the ORCHID. Currently,
Currently, truncated SHA-1, truncated SHA-384, and truncated SHA-256 truncated SHA-1, truncated SHA-384, and truncated SHA-256
[FIPS.180-2.2002] are defined as hashes for generating a HIT. [FIPS.180-2.2002] are defined as hashes for generating a HIT.
For identities that are either RSA, Digital Signature Algorithm (DSA) For identities that are either RSA, Digital Signature Algorithm (DSA)
[FIPS186-3], or Elliptic Curve DSA (ECDSA) public keys, the ORCHID [FIPS186-3], or Elliptic Curve DSA (ECDSA) public keys, the ORCHID
input consists of the public key encoding as specified for the Host input consists of the public key encoding as specified for the Host
Identity field of the HOST_ID parameter (see Section 5.2.9). This Identity field of the HOST_ID parameter (see Section 5.2.9). This
document defines four algorithm profiles: RSA, DSA, ECDSA, and 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. Hence, one of the following applies: computational capabilities. Hence, one of the following applies:
skipping to change at page 51, line 43 skipping to change at page 51, line 43
DEPRECATED 1 DEPRECATED 1
DEPRECATED 2 DEPRECATED 2
1536-bit MODP group [RFC3526] HKDF [RFC5869] 3 1536-bit MODP group [RFC3526] HKDF [RFC5869] 3
3072-bit MODP group [RFC3526] HKDF [RFC5869] 4 3072-bit MODP group [RFC3526] HKDF [RFC5869] 4
DEPRECATED 5 DEPRECATED 5
DEPRECATED 6 DEPRECATED 6
NIST P-256 [RFC5903] HKDF [RFC5869] 7 NIST P-256 [RFC5903] HKDF [RFC5869] 7
NIST P-384 [RFC5903] HKDF [RFC5869] 8 NIST P-384 [RFC5903] HKDF [RFC5869] 8
NIST P-521 [RFC5903] HKDF [RFC5869] 9 NIST P-521 [RFC5903] HKDF [RFC5869] 9
SECP160R1 [SECG] HKDF [RFC5869] 10 SECP160R1 [SECG] HKDF [RFC5869] 10
2048-bit MODP group [RFC3526] HKDF [RFC5869] 11
The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH
groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH group 10 groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH group 10
is covered in Appendix D. Any ECDH used with HIP MUST have a co- is covered in Appendix D. Any ECDH used with HIP MUST have a co-
factor of 1. factor of 1.
The Group ID also defines the key derivation function that is to be The Group ID also defines the key derivation function that is to be
used for deriving the symmetric keys for the HMAC and symmetric used for deriving the symmetric keys for the HMAC and symmetric
encryption from the keying material from the Diffie Hellman key encryption from the keying material from the Diffie Hellman key
exchange (see Section 6.5). exchange (see Section 6.5).
skipping to change at page 108, line 11 skipping to change at page 109, line 11
reference to this specification, and the existing value (128) for reference to this specification, and the existing value (128) for
R1_COUNTER left in place with a reference to [RFC5201]. This R1_COUNTER left in place with a reference to [RFC5201]. This
documents the change in value that has occurred in version 2 of documents the change in value that has occurred in version 2 of
this protocol. For clarity, we recommend that the name for the this protocol. For clarity, we recommend that the name for the
value 128 be changed from "R1_COUNTER" to "R1_Counter (v1 only)". value 128 be changed from "R1_COUNTER" to "R1_Counter (v1 only)".
A new value (579) for a new Parameter Type HIP_CIPHER should be A new value (579) for a new Parameter Type HIP_CIPHER should be
added, with reference to this specification. This Parameter Type added, with reference to this specification. This Parameter Type
functionally replaces the HIP_TRANSFORM Parameter Type (value 577) functionally replaces the HIP_TRANSFORM Parameter Type (value 577)
which can be left in the table with existing reference to which can be left in the table with existing reference to
[RFC5201]. [RFC5201]. For clarity, we recommend that the name for the value
577 be changed from "HIP_TRANSFORM" to "HIP_TRANSFORM (v1 only)".
A new value (715) for a new Parameter Type HIT_SUITE_LIST should A new value (715) for a new Parameter Type HIT_SUITE_LIST should
be added, with reference to this specification. be added, with reference to this specification.
A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST
should be added, with reference to this specification. should be added, with reference to this specification.
The name of the HMAC Parameter Type (value 61505) should be The name of the HMAC Parameter Type (value 61505) should be
changed to HIP_MAC. The name of the HMAC_2 Parameter Type (value changed to HIP_MAC. The name of the HMAC_2 Parameter Type (value
61569) should be changed to HIP_MAC_2. The reference should be 61569) should be changed to HIP_MAC_2. The reference should be
skipping to change at page 111, line 24 skipping to change at page 112, line 24
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-16 11.1. Changes from draft-ietf-hip-rfc5201-bis-17
o Update ORCHID reference to newly published RFC 7343
o Update example checksum section to RFC 7343 HIT prefix of
2001:20::/28, and fix incorrect Header Length fields
o Update IANA considerations comment on legacy HIP_TRANSFORM
parameter naming
o Add 2048-bit MODP DHE group as Group ID value 11.
11.2. Changes from draft-ietf-hip-rfc5201-bis-16
o Clarify that receipt of user data in state CLOSING (Table 7) o Clarify that receipt of user data in state CLOSING (Table 7)
results in transition to I1-SENT results in transition to I1-SENT
o Add academic reference for the first mention of the RSA algorithm o Add academic reference for the first mention of the RSA algorithm
o As part of comment resolution on use of NULL encryption, note that o As part of comment resolution on use of NULL encryption, note that
use of a NULL HIP CIPHER is only to be used when debugging and use of a NULL HIP CIPHER is only to be used when debugging and
testing the HIP protocol. This only pertains to the ENCRYPTED testing the HIP protocol. This only pertains to the ENCRYPTED
parameter, which is optional; in practice, if encryption is not parameter, which is optional; in practice, if encryption is not
desired, better to just not encrypt the Host ID. desired, better to just not encrypt the Host ID.
11.2. Changes from draft-ietf-hip-rfc5201-bis-15 11.3. Changes from draft-ietf-hip-rfc5201-bis-15
o Additional edits to IANA Considerations section based on initial o Additional edits to IANA Considerations section based on initial
IANA review. IANA review.
11.3. Changes from draft-ietf-hip-rfc5201-bis-14 11.4. Changes from draft-ietf-hip-rfc5201-bis-14
o Update source XML to comply with xmlrfcv2 version of the xml2rfc o Update source XML to comply with xmlrfcv2 version of the xml2rfc
tool, resulting in a few table formatting changes. tool, resulting in a few table formatting changes.
o Editorial and minor technical revisions based on IESG review. o Editorial and minor technical revisions based on IESG review.
o Significant revisions to IANA Considerations section based on o Significant revisions to IANA Considerations section based on
initial IANA review. initial IANA review.
11.4. Changes from draft-ietf-hip-rfc5201-bis-13 11.5. Changes from draft-ietf-hip-rfc5201-bis-13
o Update a few references and fix some editorial nits. o Update a few references and fix some editorial nits.
11.5. Changes from draft-ietf-hip-rfc5201-bis-12 11.6. Changes from draft-ietf-hip-rfc5201-bis-12
o Fix I-D nits. o Fix I-D nits.
11.6. Changes from draft-ietf-hip-rfc5201-bis-11 11.7. Changes from draft-ietf-hip-rfc5201-bis-11
o Specify that TRANSPORT_FORMAT_LIST is mandatory in R1 and I2; fix o Specify that TRANSPORT_FORMAT_LIST is mandatory in R1 and I2; fix
incorrect section reference. incorrect section reference.
11.7. Changes from draft-ietf-hip-rfc5201-bis-10 11.8. Changes from draft-ietf-hip-rfc5201-bis-10
o Issue 39: Text clarifying R1 counter rollover and Initiator o Issue 39: Text clarifying R1 counter rollover and Initiator
response to unexpected reset of the counter. response to unexpected reset of the counter.
11.8. Changes from draft-ietf-hip-rfc5201-bis-09 11.9. Changes from draft-ietf-hip-rfc5201-bis-09
o Editorial changes based on working group last call. o Editorial changes based on working group last call.
11.9. Changes from draft-ietf-hip-rfc5201-bis-08 11.10. Changes from draft-ietf-hip-rfc5201-bis-08
o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to
REQUIRED status REQUIRED status
o Issue 35: limiting ECC cofactor to 1 o Issue 35: limiting ECC cofactor to 1
o Changed text regarding issue 33 reusing DH values o Changed text regarding issue 33 reusing DH values
o Fix tracker issue 32 on Domain Identifier normative text o Fix tracker issue 32 on Domain Identifier normative text
11.10. Changes from draft-ietf-hip-rfc5201-bis-07 11.11. Changes from draft-ietf-hip-rfc5201-bis-07
o Removed lingering references to SHA-1 as the mandatory hash o Removed lingering references to SHA-1 as the mandatory hash
algorithm (which was changed to SHA-256 in the -02 draft version). algorithm (which was changed to SHA-256 in the -02 draft version).
o For parameter type number changes, changed "IETF Review" to "IETF o For parameter type number changes, changed "IETF Review" to "IETF
Review or IESG Approval". Review or IESG Approval".
o Updated Appendix C checksum examples to conform to HIPv2 packets. o Updated Appendix C checksum examples to conform to HIPv2 packets.
11.11. Changes from draft-ietf-hip-rfc5201-bis-06 11.12. Changes from draft-ietf-hip-rfc5201-bis-06
o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains
an R1_COUNTER. This required to make the R1 counter a critical an R1_COUNTER. This required to make the R1 counter a critical
parameter. Hence, the parameter type number of the R1_COUNTER parameter. Hence, the parameter type number of the R1_COUNTER
changed from 128 to 129. changed from 128 to 129.
o Made KDF dependent on DH Group to enable negotiation of the KDF. o Made KDF dependent on DH Group to enable negotiation of the KDF.
11.12. Changes from draft-ietf-hip-rfc5201-bis-05 11.13. Changes from draft-ietf-hip-rfc5201-bis-05
o Changed type number of DH_GROUP_LIST from 2151 to 511 because it 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 was in the number space that is reserved for the HIP transport
mode negotiations. mode negotiations.
o Added transport form type list parameter. Transport forms are now o Added transport form type list parameter. Transport forms are now
negotiated with this list instead of by their order in the HIP negotiated with this list instead of by their order in the HIP
packet. This allows to remove the exception of the transport packet. This allows to remove the exception of the transport
format parameters that were ordered by their preference instead of format parameters that were ordered by their preference instead of
by their type number. This should remove complexity from by their type number. This should remove complexity from
skipping to change at page 113, line 43 skipping to change at page 115, line 10
o Permit using Anonymous HI control in packets other than R1/I2. o Permit using Anonymous HI control in packets other than R1/I2.
o Fixed minor reference error (RFC2418, RFC2410). o Fixed minor reference error (RFC2418, RFC2410).
o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable
via the UI. via the UI.
o Editorial changes. o Editorial changes.
11.13. Changes from draft-ietf-hip-rfc5201-bis-04 11.14. 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 115, line 9 skipping to change at page 116, line 23
o Changed IETF Consensus to IETF Review or IESG Approval in IANA o Changed IETF Consensus to IETF Review or IESG Approval in IANA
section. 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.14. Changes from draft-ietf-hip-rfc5201-bis-03 11.15. 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 115, line 45 skipping to change at page 117, line 10
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.15. Changes from draft-ietf-hip-rfc5201-bis-02 11.16. 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.16. Changes from draft-ietf-hip-rfc5201-bis-01 11.17. 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 118, line 9 skipping to change at page 119, line 21
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.17. Changes from draft-ietf-hip-rfc5201-bis-00 11.18. 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.18. Contents of draft-ietf-hip-rfc5201-bis-00 11.19. 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] [FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, Hash Standard", FIPS PUB 180-2, August 2002,
<http://csrc.nist.gov/publications/fips/fips180-2/ <http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2.pdf>. fips180-2.pdf>.
[I-D.ietf-hip-rfc4843-bis]
Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
Routable Cryptographic Hash Identifiers Version 2
(ORCHIDv2)", draft-ietf-hip-rfc4843-bis-04 (work in
progress), May 2013.
[I-D.ietf-hip-rfc5202-bis] [I-D.ietf-hip-rfc5202-bis]
Jokela, P., Moskowitz, R., and J. Melen, "Using the Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", draft-ietf-hip- the Host Identity Protocol (HIP)", draft-ietf-hip-
rfc5202-bis-05 (work in progress), November 2013. rfc5202-bis-05 (work in progress), November 2013.
[NIST.800-131A.2011] [NIST.800-131A.2011]
National Institute of Standards and Technology, National Institute of Standards and Technology,
"Transitions: Recommendation for Transitioning the Use of "Transitions: Recommendation for Transitioning the Use of
Cryptographic Algorithms and Key Lengths", NIST 800-131A, Cryptographic Algorithms and Key Lengths", NIST 800-131A,
skipping to change at page 120, line 13 skipping to change at page 121, line 20
384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC", RFC 5702, October and RRSIG Resource Records for DNSSEC", RFC 5702, October
2009. 2009.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
Routable Cryptographic Hash Identifiers Version 2
(ORCHIDv2)", RFC 7343, September 2014.
12.2. Informative References 12.2. Informative References
[AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the
HIP Base Exchange Protocol", in Proceedings of 10th HIP Base Exchange Protocol", in Proceedings of 10th
Australasian Conference on Information Security and Australasian Conference on Information Security and
Privacy, July 2003. Privacy, July 2003.
[CRO03] Crosby, SA. and DS. Wallach, "Denial of Service via [CRO03] Crosby, SA. and DS. Wallach, "Denial of Service via
Algorithmic Complexity Attacks", in Proceedings of Usenix Algorithmic Complexity Attacks", in Proceedings of Usenix
Security Symposium 2003, Washington, DC., August 2003. Security Symposium 2003, Washington, DC., August 2003.
skipping to change at page 124, line 47 skipping to change at page 125, line 47
buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 +
8 * HI.DSA.T ) 8 * HI.DSA.T )
break; break;
} }
Appendix C. Example Checksums for HIP Packets Appendix C. Example Checksums for HIP Packets
The HIP checksum for HIP packets is specified in Section 5.1.1. The HIP checksum for HIP packets is specified in Section 5.1.1.
Checksums for TCP and UDP packets running over HIP-enabled security Checksums for TCP and UDP packets running over HIP-enabled security
associations are specified in Section 3.5. The examples below use associations are specified in Section 4.5.1. The examples below use
[RFC3849] and [RFC5747] addresses, and HITs with the prefix of [RFC3849] and [RFC5747] addresses, and HITs with the prefix of
2001:10 followed by zeros, followed by a decimal 1 or 2, 2001:20 followed by zeros, followed by a decimal 1 or 2,
respectively. respectively.
The following example is defined only for testing the checksum The following example is defined only for testing the checksum
calculation. calculation.
C.1. IPv6 HIP Example (I1 packet) C.1. IPv6 HIP Example (I1 packet)
Source Address: 2001:D88::1 Source Address: 2001:D88::1
Destination Address: 2001:D88::2 Destination Address: 2001:D88::2
Upper-Layer Packet Length: 48 0x30 Upper-Layer Packet Length: 48 0x30
Next Header: 139 0x8b Next Header: 139 0x8b
Payload Protocol: 59 0x3b Payload Protocol: 59 0x3b
Header Length: 4 0x4 Header Length: 5 0x5
Packet Type: 1 0x1 Packet Type: 1 0x1
Version: 2 0x2 Version: 2 0x2
Reserved: 1 0x1 Reserved: 1 0x1
Control: 0 0x0 Control: 0 0x0
Checksum: 6878 0x1ade Checksum: 6846 0x1abe
Sender's HIT : 2001:10::1 Sender's HIT : 2001:20::1
Receiver's HIT: 2001:10::2 Receiver's HIT: 2001:20::2
DH_GROUP_LIST type: 511 0x1ff DH_GROUP_LIST type: 511 0x1ff
DH_GROUP_LIST length: 3 0x3 DH_GROUP_LIST length: 3 0x3
DH_GROUP_LIST group IDs: 3,4,8 DH_GROUP_LIST group IDs: 3,4,8
C.2. IPv4 HIP Packet (I1 packet) C.2. IPv4 HIP Packet (I1 packet)
The IPv4 checksum value for the example I1 packet is shown below. The IPv4 checksum value for the example I1 packet is shown below.
Source Address: 192.0.2.1 Source Address: 192.0.2.1
Destination Address: 192.0.2.2 Destination Address: 192.0.2.2
Upper-Layer Packet Length: 48 0x30 Upper-Layer Packet Length: 48 0x30
Next Header: 139 0x8b Next Header: 139 0x8b
Payload Protocol: 59 0x3b Payload Protocol: 59 0x3b
Header Length: 4 0x4 Header Length: 5 0x5
Packet Type: 1 0x1 Packet Type: 1 0x1
Version: 2 0x2 Version: 2 0x2
Reserved: 1 0x1 Reserved: 1 0x1
Control: 0 0x0 Control: 0 0x0
Checksum: 61934 0xf1ee Checksum: 61902 0xf1ce
Sender's HIT : 2001:10::1 Sender's HIT : 2001:20::1
Receiver's HIT: 2001:10::2 Receiver's HIT: 2001:20::2
DH_GROUP_LIST type: 511 0x1ff DH_GROUP_LIST type: 511 0x1ff
DH_GROUP_LIST length: 3 0x3 DH_GROUP_LIST length: 3 0x3
DH_GROUP_LIST group IDs: 3,4,8 DH_GROUP_LIST group IDs: 3,4,8
C.3. TCP Segment C.3. TCP Segment
Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets
use the IPv6 pseudo-header format [RFC2460], with the HITs used in use the IPv6 pseudo-header format [RFC2460], with the HITs used in
place of the IPv6 addresses. place of the IPv6 addresses.
Sender's HIT: 2001:10::1 Sender's HIT: 2001:20::1
Receiver's HIT: 2001:10::2 Receiver's HIT: 2001:20::2
Upper-Layer Packet Length: 20 0x14 Upper-Layer Packet Length: 20 0x14
Next Header: 6 0x06 Next Header: 6 0x06
Source port: 65500 0xffdc Source port: 65500 0xffdc
Destination port: 22 0x0016 Destination port: 22 0x0016
Sequence number: 1 0x00000001 Sequence number: 1 0x00000001
Acknowledgment number: 0 0x00000000 Acknowledgment number: 0 0x00000000
Header length: 20 0x14 Data offset: 5 0x5
Flags: SYN 0x02 Flags: SYN 0x02
Window size: 65535 0xffff Window size: 65535 0xffff
Checksum: 28618 0x6fca Checksum: 28586 0x6faa
Urgent pointer: 0 0x0000 Urgent pointer: 0 0x0000
0x0000: 6000 0000 0014 0640 2001 0010 0000 0000
0x0010: 0000 0000 0000 0001 2001 0010 0000 0000
0x0020: 0000 0000 0000 0002 ffdc 0016 0000 0001
0x0030: 0000 0000 5002 ffff 6fca 0000
Appendix D. ECDH and ECDSA 160 Bit Groups Appendix D. ECDH and ECDSA 160 Bit Groups
The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits
symmetric strength. Once this was considered appropriate for one symmetric strength. Once this was considered appropriate for one
year of security. Today these groups should be used only when the year of security. Today these groups should be used only when the
host is not powerful enough (e.g., some embedded devices) and when host is not powerful enough (e.g., some embedded devices) and when
security requirements are low (e.g., long-term confidentiality is not security requirements are low (e.g., long-term confidentiality is not
required). required).
Appendix E. HIT Suites and HIT Generation Appendix E. HIT Suites and HIT Generation
The HIT as an ORCHID [I-D.ietf-hip-rfc4843-bis] consists of three The HIT as an ORCHID [RFC7343] consists of three parts: A 28-bit
parts: A 28-bit prefix, a 4-bit encoding of the ORCHID generation prefix, a 4-bit encoding of the ORCHID generation algorithm (OGA) and
algorithm (OGA) and the representation of the public key. The OGA is the representation of the public key. The OGA is an index pointing
an index pointing to the specific algorithm by which the public key to the specific algorithm by which the public key and the 96-bit
and the 96-bit hashed encoding is generated. The OGA is protocol hashed encoding is generated. The OGA is protocol specific and is to
specific and is to be interpreted as defined below for all protocols be interpreted as defined below for all protocols that use the same
that use the same context ID as HIP. HIP groups sets of valid context ID as HIP. HIP groups sets of valid combinations of
combinations of signature and hash algorithms into HIT Suites. These signature and hash algorithms into HIT Suites. These HIT suites are
HIT suites are addressed by an index, which is transmitted in the OGA addressed by an index, which is transmitted in the OGA field of the
field of the ORCHID. ORCHID.
The set of used HIT Suites will be extended to counter the progress The set of used HIT Suites will be extended to counter the progress
in computation capabilities and vulnerabilities in the employed in computation capabilities and vulnerabilities in the employed
algorithms. The intended use of the HIT Suites is to introduce a new algorithms. The intended use of the HIT Suites is to introduce a new
HIT Suite and phase out an old one before it becomes insecure. Since HIT Suite and phase out an old one before it becomes insecure. Since
the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID
0 is reserved) to be used in parallel, phased-out HIT Suites must be 0 is reserved) to be used in parallel, phased-out HIT Suites must be
reused at some point. In such a case, there will be a rollover of reused at some point. In such a case, there will be a rollover of
the HIT Suite ID and the next newly introduced HIT Suite will start the HIT Suite ID and the next newly introduced HIT Suite will start
with a lower HIT Suite index than the previously introduced one. The with a lower HIT Suite index than the previously introduced one. The
 End of changes. 46 change blocks. 
167 lines changed or deleted 173 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/