draft-ietf-hip-rfc5201-bis-14.txt   draft-ietf-hip-rfc5201-bis-15.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 Intended status: Standards Track Hirschmann Automation and Control
Expires: April 9, 2014 Control Expires: January 24, 2015 P. Jokela
P. Jokela
Ericsson Research NomadicLab Ericsson Research NomadicLab
T. Henderson T. Henderson
The Boeing Company University of Washington
October 6, 2013 July 23, 2014
Host Identity Protocol Version 2 (HIPv2) Host Identity Protocol Version 2 (HIPv2)
draft-ietf-hip-rfc5201-bis-14 draft-ietf-hip-rfc5201-bis-15
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 Diffie-
compliant Diffie-Hellman key exchange, using public key identifiers Hellman key exchange, using public key identifiers from a new Host
from a new Host Identity namespace for mutual peer authentication. Identity namespace for mutual peer authentication. The protocol is
The protocol is designed to be resistant to denial-of-service (DoS) designed to be resistant to denial-of-service (DoS) and man-in-the-
and man-in-the-middle (MitM) attacks. When used together with middle (MitM) attacks. When used together with another suitable
another suitable security protocol, such as the Encapsulated Security security protocol, such as the Encapsulated Security Payload (ESP),
Payload (ESP), it provides integrity protection and optional it provides integrity protection and optional encryption for upper-
encryption for upper-layer protocols, such as TCP and UDP. layer protocols, such as TCP and UDP.
This document obsoletes RFC 5201 and addresses the concerns raised by This document obsoletes RFC 5201 and addresses the concerns raised by
the IESG, particularly that of crypto agility. It also incorporates the IESG, particularly that of crypto agility. It also incorporates
lessons learned from the implementations of RFC 5201. lessons learned from the implementations of RFC 5201.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 9, 2014. This Internet-Draft will expire on January 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. A New Namespace and Identifiers . . . . . . . . . . . . 7 1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 6
1.2. The HIP Base Exchange (BEX) . . . . . . . . . . . . . . 7 1.2. The HIP Base Exchange (BEX) . . . . . . . . . . . . . . . 6
1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 8 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 7
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 10 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . 11 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . 11 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 13 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 14 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 14
4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 15 4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 15
4.1.3. Authenticated Diffie-Hellman Protocol with DH 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group
Group Negotiation . . . . . . . . . . . . . . . . . . 17 Negotiation . . . . . . . . . . . . . . . . . . . . . 16
4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 18 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 18
4.1.5. Refusing a HIP Base Exchange . . . . . . . . . . . . 19 4.1.5. Refusing a HIP base exchange . . . . . . . . . . . . 19
4.1.6. Aborting a HIP Base Exchange . . . . . . . . . . . . 20 4.1.6. Aborting a HIP base exchange . . . . . . . . . . . . 19
4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 20 4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 20
4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 21 4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 21
4.2. Updating a HIP Association . . . . . . . . . . . . . . . 24 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 23
4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 25 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 24
4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . 26 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 25
4.4.1. State Machine Terminology . . . . . . . . . . . . . . 26 4.4.1. State Machine Terminology . . . . . . . . . . . . . . 26
4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 27 4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 26
4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 27 4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 27
4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 35 4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 35
4.5. User Data Considerations . . . . . . . . . . . . . . . . 37 4.5. User Data Considerations . . . . . . . . . . . . . . . . 37
4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 37 4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 37
4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 37 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 37
4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 37 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 37
4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 37 4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 37
4.6. Certificate Distribution . . . . . . . . . . . . . . . . 38 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 38
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 38 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 38
5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 40 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 40
5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 40 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 40
5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 40 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 40
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 41 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 41
5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 44 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 44
5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 46 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 46
5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 47 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46
5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 48 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 49 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48
5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 50 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 . . . . . . . . . . . . . . . . . . . . . . 57
5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 58 5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 58
5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 59 5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 59
5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 61 5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 60
5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 62 5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 62
5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 66 5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 65
5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 66 5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 66
5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 67 5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 66
5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 68 5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 67
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . 68 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 68
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 69 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 69
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 70 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 69
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 73 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 72
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 74 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 74
5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 75 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 74
5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 76 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 75
5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 76 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 76
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 77 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 76
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . 77 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 77
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 77 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 77
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 . . . . . . . . . . . . . . . . . . . . . . 77
5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 78 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 77
5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 78 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 78
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 78 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 78
6.1. Processing Outgoing Application Data . . . . . . . . . . 79 6.1. Processing Outgoing Application Data . . . . . . . . . . 78
6.2. Processing Incoming Application Data . . . . . . . . . . 80 6.2. Processing Incoming Application Data . . . . . . . . . . 79
6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 81 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 80
6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 82 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 82
6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 82 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 82
6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 85 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 84
6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . 87 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 86
6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . 88 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 88
6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 89 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 89
6.6.2. Processing Incoming ICMP Protocol Unreachable 6.6.2. Processing Incoming ICMP Protocol Unreachable
Messages . . . . . . . . . . . . . . . . . . . . . . 90 Messages . . . . . . . . . . . . . . . . . . . . . . 89
6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 90 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 90
6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 91 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 91
6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 92 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 91
6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 92 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 92
6.8.1. Handling of Malformed Messages . . . . . . . . . . . 95 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 94
6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 95 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 94
6.9.1. Handling of Malformed Messages . . . . . . . . . . . 98 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 97
6.10. Processing of Incoming R2 Packets . . . . . . . . . . . 98 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 98
6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 98 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 98
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 99 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 99
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 . . . . . . . . . . . . . . . . . . . . . . 100
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 . . . . . . . . . . . . . . . . . . . . . . . 101
6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 102 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 101
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 102 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 102
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 102 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 102
6.16. Handling State Loss . . . . . . . . . . . . . . . . . . 102 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 102
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 103 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 103
8. Security Considerations . . . . . . . . . . . . . . . . . . . 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 103
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 108 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 110
11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 109 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 111
11.1. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 109 11.1. Changes from draft-ietf-hip-rfc5201-bis-14 . . . . . . . 111
11.2. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 110 11.2. Changes from draft-ietf-hip-rfc5201-bis-13 . . . . . . . 111
11.3. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 110 11.3. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 111
11.4. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 110 11.4. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 111
11.5. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 110 11.5. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 111
11.6. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 110 11.6. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 111
11.7. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 110 11.7. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 111
11.8. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 111 11.8. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 112
11.9. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 111 11.9. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 112
11.10. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 113 11.10. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 112
11.11. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 113 11.11. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 113
11.12. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 114 11.12. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 114
11.13. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 116 11.13. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 115
11.14. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 116 11.14. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 115
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 116 11.15. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 117
12.1. Normative References . . . . . . . . . . . . . . . . . . 116 11.16. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 117
12.2. Informative References . . . . . . . . . . . . . . . . . 118 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 117
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 121 12.1. Normative References . . . . . . . . . . . . . . . . . . 117
Appendix B. Generating a Public Key Encoding from an HI . . . . 122 12.2. Informative References . . . . . . . . . . . . . . . . . 119
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 122
Appendix B. Generating a Public Key Encoding from an HI . . 123
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 123 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 123
C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 123 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 124
C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . 123 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 124
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . 124 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 125
Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 125 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 125
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 125 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 125
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
skipping to change at page 6, line 24 skipping to change at page 5, line 40
key pair, are used as Host Identifiers, to which higher layer key pair, are used as Host Identifiers, to which higher layer
protocols are bound instead of an IP address. By using public keys protocols are bound instead of an IP address. By using public keys
(and their representations) as host identifiers, dynamic changes to (and their representations) as host identifiers, dynamic changes to
IP address sets can be directly authenticated between hosts, and if IP address sets can be directly authenticated between hosts, and if
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 and terminating an active HIP
elements of the HIP architecture are specified in other documents, association. Other elements of the HIP architecture are specified in
such as: other documents, 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
o "Host Identity Protocol (HIP) Rendezvous Extension" o "Host Identity Protocol (HIP) Rendezvous Extension"
[I-D.ietf-hip-rfc5204-bis]: using a rendezvous mechanism to [I-D.ietf-hip-rfc5204-bis]: using a rendezvous mechanism to
contact mobile HIP hosts contact mobile HIP hosts
Since the HIP Base Exchange was first developed, there have been a Since the HIP base exchange was first developed, there have been a
few advances in cryptography and attacks against cryptographic few advances in cryptography and attacks against cryptographic
systems. As a result, all cryptographic protocols need to be agile. systems. As a result, all cryptographic protocols need to be agile.
That is, it should be a part of the protocol to be able to switch That is, it should be a part of the protocol to be able to switch
from one cryptographic primitive to another. It is important to from one cryptographic primitive to another. It is important to
support a reasonable set of mainstream algorithms to cater for support a reasonable set of mainstream algorithms to cater for
different use cases and allow moving away from algorithms that are different use cases and allow moving away from algorithms that are
later discovered to be vulnerable This update to the Base Exchange later discovered to be vulnerable. This update to the base exchange
includes this needed cryptographic agility while addressing the includes this needed cryptographic agility while addressing the
downgrade attacks that such flexibility introduces. In particular, downgrade attacks that such flexibility introduces. In particular,
Elliptic Curve support by Elliptic Curve DSA (ECDSA) and Elliptic Elliptic Curve support by Elliptic Curve DSA (ECDSA) and Elliptic
Curve Diffie-Hellman (ECDH) and alternative hash functions have been Curve Diffie-Hellman (ECDH) and alternative hash functions have been
added. added.
1.1. A New Namespace and Identifiers 1.1. A New Namespace and Identifiers
The Host Identity Protocol introduces a new namespace, the Host The Host Identity Protocol introduces a new namespace, the Host
Identity namespace. Some ramifications of this new namespace are Identity namespace. Some ramifications of this new namespace are
skipping to change at page 9, line 19 skipping to change at page 8, line 35
<-- signifies "Responder to Initiator" communication (replies). <-- signifies "Responder to Initiator" communication (replies).
| signifies concatenation of information (e.g., X | Y is the | signifies concatenation of information (e.g., X | Y is the
concatenation of X with Y). concatenation of X with Y).
Ltrunc (H(x), K) denotes the lowest order #K bits of the result of Ltrunc (H(x), K) denotes the lowest order #K bits of the result of
the hash function H on the input x. the hash function H on the input x.
2.3. Definitions 2.3. Definitions
HIP Base Exchange (BEX): the handshake for establishing a new HIP HIP base exchange (BEX): the handshake for establishing a new HIP
association. association.
Host Identity (HI): The public key of the signature algorithm that Host Identity (HI): The public key of the signature algorithm that
represents the identity of the host. In HIP, a host proves its represents the identity of the host. In HIP, a host proves its
identity by creating a signature with the private key belonging to identity by creating a signature with the private key belonging to
its HI (c.f. Section 3). its HI (c.f. Section 3).
Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It
is generated by hashing the HI (c.f. Section 3.1). is generated by hashing the HI (c.f. Section 3.1).
HIT Suite: A HIT Suite groups all cryptographic algorithms that are HIT Suite: A HIT Suite groups all cryptographic algorithms that are
required to generate and use an HI and its HIT. In particular, required to generate and use an HI and its HIT. In particular,
these algorithms are: 1) the public key signature algorithm and 2) these algorithms are: 1) the public key signature algorithm and 2)
the hash function, 3) the truncation (c.f. Appendix E). the hash function, 3) the truncation (c.f. Appendix E).
HIP association: The shared state between two peers after HIP association: The shared state between two peers after
completion of the BEX. completion of the BEX.
HIP packet: A control packet carrying a HIP packet header relating
to the establishment, maintenance, or termination of the HIP
association.
Initiator: The host that initiates the BEX. This role is typically Initiator: The host that initiates the BEX. This role is typically
forgotten once the BEX is completed. forgotten once the BEX is completed.
Responder: The host that responds to the Initiator in the BEX. Responder: The host that responds to the Initiator in the BEX.
This role is typically forgotten once the BEX is completed. This role is typically forgotten once the BEX is completed.
Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for
various hash calculations in this document. The algorithm is the various hash calculations in this document. The algorithm is the
same as is used to generate the Responder's HIT. The RHASH is the same as is used to generate the Responder's HIT. The RHASH is the
hash function defined by the HIT Suite of the Responder's HIT hash function defined by the HIT Suite of the Responder's HIT
skipping to change at page 10, line 17 skipping to change at page 9, line 33
Signed data: Data that is signed is protected by a digital Signed data: Data that is signed is protected by a digital
signature that was created by the sender of the data by using the signature that was created by the sender of the data by using the
private key of its HI. private key of its HI.
KDF: The Key Derivation Function (KDF) is used for deriving the KDF: The Key Derivation Function (KDF) is used for deriving the
symmetric keys from the Diffie-Hellman key exchange. symmetric keys from the Diffie-Hellman key exchange.
KEYMAT: The keying material derived from the Diffie-Hellman key KEYMAT: The keying material derived from the Diffie-Hellman key
exchange by using the KDF. Symmetric keys for encryption and exchange by using the KDF. Symmetric keys for encryption and
integrity protection of HIP control and payload packets are drawn integrity protection of HIP packets and encrypted user data
from this keying material. packets are drawn from this keying material.
3. Host Identity (HI) and its Structure 3. Host Identity (HI) and its Structure
In this section, the properties of the Host Identity and Host In this section, the properties of the Host Identity and Host
Identity Tag are discussed, and the exact format for them is defined. Identity Tag are discussed, and the exact format for them is defined.
In HIP, the public key of an asymmetric key pair is used as the Host In HIP, the public key of an asymmetric key pair is used as the Host
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
skipping to change at page 11, line 40 skipping to change at page 11, line 9
defined in [I-D.ietf-hip-rfc4843-bis]. The Host Identity Tag is one defined in [I-D.ietf-hip-rfc4843-bis]. 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 hosts 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 [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.9) present in a that encodes the Host Identity field (see Section 5.2.9) present in a
skipping to change at page 12, line 35 skipping to change at page 12, line 5
The DSA public key is encoded as defined in [RFC2536] Section 2, The DSA public key is encoded as defined in [RFC2536] Section 2,
taking the fields T, Q, P, G, and Y, concatenated as input. Thus, taking the fields T, Q, P, G, and Y, concatenated as input. Thus,
the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long,
where T is the size parameter as defined in [RFC2536]. The size where T is the size parameter as defined in [RFC2536]. The size
parameter T, affecting the field lengths, MUST be selected as the parameter T, affecting the field lengths, MUST be selected as the
minimum value that is long enough to accommodate P, G, and Y. The minimum value that is long enough to accommodate P, G, and Y. The
fields MUST be encoded in network byte order, as defined in fields MUST be encoded in network byte order, as defined in
[RFC2536]. [RFC2536].
The ECDSA public keys are encoded as defined in [RFC6090] Section The ECDSA public keys are encoded as defined in [RFC6090]
4.2 and 6. Section 4.2 and 6.
In Appendix B, the public key encoding process is illustrated using In Appendix B, the public key encoding process is illustrated using
pseudo-code. pseudo-code.
4. Protocol Overview 4. Protocol Overview
This section is a simplified overview of the HIP protocol operation, This section is a simplified overview of the HIP protocol operation,
and does not contain all the details of the packet formats or the and does not contain all the details of the packet formats or the
packet processing steps. Sections 5 and 6 describe in more detail packet processing steps. Sections 5 and 6 describe in more detail
the packet formats and packet processing steps, respectively, and are the packet formats and packet processing steps, respectively, and are
skipping to change at page 15, line 7 skipping to change at page 14, line 34
4.1.1. HIP Puzzle Mechanism 4.1.1. HIP Puzzle Mechanism
The purpose of the HIP puzzle mechanism is to protect the Responder The purpose of the HIP puzzle mechanism is to protect the Responder
from a number of denial-of-service threats. It allows the Responder from a number of denial-of-service threats. It allows the Responder
to delay state creation until receiving the I2 packet. Furthermore, to delay state creation until receiving the I2 packet. Furthermore,
the puzzle allows the Responder to use a fairly cheap calculation to the puzzle allows the Responder to use a fairly cheap calculation to
check that the Initiator is "sincere" in the sense that it has check that the Initiator is "sincere" in the sense that it has
churned enough CPU cycles in solving the puzzle. churned enough CPU cycles in solving the puzzle.
The puzzle allows a Responder implementation to completely delay The puzzle allows a Responder implementation to completely delay
session-specific state creation until a valid I2 packet is received. association-specific state creation until a valid I2 packet is
An I2 packet without valid puzzle solution can be rejected received. An I2 packet without valid puzzle solution can be rejected
immediately once the Responder has checked the solution by computing immediately once the Responder has checked the solution by computing
only one hash function before state is created and CPU-intensive only one hash function before state is created and CPU-intensive
public-key signature verification and Diffie-Hellman key generation public-key signature verification and Diffie-Hellman key generation
are performed. By varying the difficulty of the puzzle, the are performed. By varying the difficulty of the puzzle, the
Responder can frustrate CPU or memory targeted DoS attacks. Responder can frustrate CPU or memory targeted DoS attacks.
The Responder can remain stateless and drop most spoofed I2 packets The Responder can remain stateless and drop most spoofed I2 packets
because puzzle calculation is based on the Initiator's Host Identity because puzzle calculation is based on the Initiator's Host Identity
Tag. The idea is that the Responder has a (perhaps varying) number of Tag. The idea is that the Responder has a (perhaps varying) number of
pre-calculated R1 packets, and it selects one of these based on the pre-calculated R1 packets, and it selects one of these based on the
skipping to change at page 16, line 48 skipping to change at page 16, line 27
it avoids problems with the validity of puzzles if the lifetime is it avoids problems with the validity of puzzles if the lifetime is
relatively short compared to the network delay and the time for relatively short compared to the network delay and the time for
solving the puzzle. solving the puzzle.
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.20) or in an ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an
ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21) 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.
skipping to change at page 19, line 18 skipping to change at page 18, line 45
each Host Identity, if there is more than one local host identity. each Host Identity, if there is more than one local host identity.
The value of this counter SHOULD be preserved across system reboots The value of this counter SHOULD be preserved across system reboots
and invocations of the HIP base exchange. This counter indicates the and invocations of the HIP base exchange. This counter indicates the
current generation of puzzles. Implementations MUST accept puzzles current generation of puzzles. Implementations MUST accept puzzles
from the current generation and MAY accept puzzles from earlier from the current generation and MAY accept puzzles from earlier
generations. A system's local counter MUST be incremented at least generations. A system's local counter MUST be incremented at least
as often as every time old R1s cease to be valid. The local counter as often as every time old R1s cease to be valid. The local counter
SHOULD never be decremented, otherwise the host exposes its peers to SHOULD never be decremented, otherwise the host exposes its peers to
the replay of previously generated, higher numbered R1s. the replay of previously generated, higher numbered R1s.
The R1 generation counter may roll over or may become reset. It is
important for an Initiator to be robust to the loss of state about
the R1 generation counter of a peer, or to a reset of the peer's
counter. It is recommended that, when choosing between multiple R1s,
the Initiator prefer to use the R1 that corresponds to the current R1
generation counter, but that if it is unable to make progress with
that R1, the Initiator may try the other R1s beginning with the R1
packet with the highest counter.
A host may receive more than one R1, either due to sending multiple A host may receive more than one R1, either due to sending multiple
I1 packets (see Section 6.6.1) or due to a replay of an old R1. When I1 packets (see Section 6.6.1) or due to a replay of an old R1. When
sending multiple I1 packets to the same host, an Initiator SHOULD sending multiple I1 packets to the same host, an Initiator SHOULD
wait for a small amount of time (a reasonable time may be 2 * wait for a small amount of time (a reasonable time may be 2 *
expected RTT) after the first R1 reception to allow possibly multiple expected RTT) after the first R1 reception to allow possibly multiple
R1s to arrive, and it SHOULD respond to an R1 among the set with the R1s to arrive, and it SHOULD respond to an R1 among the set with the
largest R1 generation counter. If an Initiator is processing an R1 largest R1 generation counter. If an Initiator is processing an R1
or has already sent an I2 packet (still waiting for the R2 packet) or has already sent an I2 packet (still waiting for the R2 packet)
and it receives another R1 with a larger R1 generation counter, it and it receives another R1 with a larger R1 generation counter, it
MAY elect to restart R1 processing with the fresher R1, as if it were MAY elect to restart R1 processing with the fresher R1, as if it were
the first R1 to arrive. the first R1 to arrive.
4.1.5. Refusing a HIP Base Exchange The R1 generation counter may roll over or may become reset. It is
important for an Initiator to be robust to the loss of state about
the R1 generation counter of a peer, or to a reset of the peer's
counter. It is recommended that, when choosing between multiple R1s,
the Initiator prefer to use the R1 that corresponds to the current R1
generation counter, but that if it is unable to make progress with
that R1, the Initiator may try the other R1s beginning with the R1
packet with the highest counter.
4.1.5. Refusing a HIP base exchange
A HIP-aware host may choose not to accept a HIP base exchange. If A HIP-aware host may choose not to accept a HIP base exchange. If
the host's policy is to only be an Initiator, it should begin its own the host's policy is to only be an Initiator, and policy allows the
HIP base exchange. A host MAY choose to have such a policy since establishment of a HIP association with the original Initiator, it
only the privacy of the Initiator's HI is protected in the exchange. should begin its own HIP base exchange. A host MAY choose to have
It should be noted that such behavior can introduce the risk of a such a policy since only the privacy of the Initiator's HI is
race condition if each host's policy is to only be an Initiator, at protected in the exchange. It should be noted that such behavior can
which point the HIP base exchange will fail. introduce the risk of a race condition if each host's policy is to
only be an Initiator, at which point the HIP base exchange will fail.
If the host's policy does not permit it to enter into a HIP exchange If the host's policy does not permit it to enter into a HIP exchange
with the Initiator, it should send an ICMP 'Destination Unreachable, with the Initiator, it should send an ICMP 'Destination Unreachable,
Administratively Prohibited' message. A more complex HIP packet is Administratively Prohibited' message. A more complex HIP packet is
not used here as it actually opens up more potential DoS attacks than not used here as it actually opens up more potential DoS attacks than
a simple ICMP message. A HIP NOTIFY message is not used because no a simple ICMP message. A HIP NOTIFY message is not used because no
HIP session exists between the two hosts at that time. HIP association exists between the two hosts at that time.
4.1.6. Aborting a HIP Base Exchange 4.1.6. Aborting a HIP base exchange
Two HIP hosts may encounter situations in which they cannot complete Two HIP hosts may encounter situations in which they cannot complete
a HIP base exchange because of insufficient support for cryptographic a HIP base exchange because of insufficient support for cryptographic
algorithms, in particular the HIT Suites and DH Groups. After algorithms, in particular the HIT Suites and DH Groups. After
receiving the R1 packet, the Initiator can determine whether the receiving the R1 packet, the Initiator can determine whether the
Responder supports the required cryptographic operations to Responder supports the required cryptographic operations to
successfully establish a HIP association. The Initiator can abort successfully establish a HIP association. The Initiator can abort
the BEX silently after receiving an R1 packet that indicates an the BEX silently after receiving an R1 packet that indicates an
unsupported set of algorithms. The specific conditions are described unsupported set of algorithms. The specific conditions are described
below. below.
skipping to change at page 21, line 51 skipping to change at page 21, line 32
It is possible to initiate a HIP BEX even if the Responder's HI (and It is possible to initiate a HIP BEX even if the Responder's HI (and
HIT) is unknown. In this case, the initial I1 packet contains all HIT) is unknown. In this case, the initial I1 packet contains all
zeros as the destination HIT. This kind of connection setup is zeros as the destination HIT. This kind of connection setup is
called opportunistic mode. called opportunistic mode.
The Responder may have multiple HITs due to multiple supported HIT The Responder may have multiple HITs due to multiple supported HIT
Suites. Since the Responder's HIT Suite in the opportunistic mode is Suites. Since the Responder's HIT Suite in the opportunistic mode is
not determined by the destination HIT of the I1 packet, the Responder not determined by the destination HIT of the I1 packet, the Responder
can freely select a HIT of any HIT Suite. The complete set of HIT can freely select a HIT of any HIT Suite. The complete set of HIT
Suites supported by the Initiator is not known to the Responder. Suites supported by the Initiator is not known to the Responder.
Therefore, the Responder SHOULD should select its HIT from the same Therefore, the Responder SHOULD select its HIT from the same HIT
HIT Suite as the Initiator's HIT (indicated by the HIT suite Suite as the Initiator's HIT (indicated by the HIT suite information
information in the OGA field of the Initiator's HIT) because this HIT in the OGA field of the Initiator's HIT) because this HIT Suite is
Suite is obviously supported by the Initiator. If the Responder obviously supported by the Initiator. If the Responder selects a
selects a different HIT that is not supported by the Initiator, the different HIT that is not supported by the Initiator, the Initiator
Initiator MAY restart the BEX with an I1 packet with a source HIT MAY restart the BEX with an I1 packet with a source HIT that is
that is contained in the list of the Responder's HIT Suites in the R1 contained in the list of the Responder's HIT Suites in the R1 packet.
packet.
Note that the Initiator cannot verify the signature of the R1 packet Note that the Initiator cannot verify the signature of the R1 packet
if the Responder's HIT Suite is not supported. Therefore, the if the Responder's HIT Suite is not supported. Therefore, the
Initiator MUST treat R1 packets with unsupported Responder HITs as Initiator MUST treat R1 packets with unsupported Responder HITs as
potentially forged and MUST NOT use any parameters from the potentially forged and MUST NOT use any parameters from the
unverified R1 besides the HIT Suite List. Moreover, an Initiator unverified R1 besides the HIT Suite List. Moreover, an Initiator
that uses an unverified HIT Suite List from an R1 packet to determine that uses an unverified HIT Suite List from an R1 packet to determine
a possible source HIT MUST verify that the HIT_SUITE_LIST in the a possible source HIT MUST verify that the HIT_SUITE_LIST in the
first unverified R1 packet matches the HIT_SUITE_LIST in the second first unverified R1 packet matches the HIT_SUITE_LIST in the second
R1 packet for which the Initiator supports the signature algorithm. R1 packet for which the Initiator supports the signature algorithm.
skipping to change at page 22, line 42 skipping to change at page 22, line 22
base exchange solely based on locators. The Responder's HI will be base exchange solely based on locators. The Responder's HI will be
tentatively available in the R1 packet, and in an authenticated form tentatively available in the R1 packet, and in an authenticated form
once the R2 packet has been received and verified. Hence, the once the R2 packet has been received and verified. Hence, the
Responder's HIT could be communicated to the application via new API Responder's HIT could be communicated to the application via new API
mechanisms. However, with a backwards-compatible API the application mechanisms. However, with a backwards-compatible API the application
sees only the locators used for the initial contact. Depending on sees only the locators used for the initial contact. Depending on
the desired semantics of the API, this can raise the following the desired semantics of the API, this can raise the following
issues: issues:
o The actual locators may later change if an UPDATE message is used, o The actual locators may later change if an UPDATE message is used,
even if from the API perspective the session still appears to be even if from the API perspective the association still appears to
between two specific locators. However, the locator update is be between two specific locators. However, the locator update is
still secure and the session is still between the same nodes. still secure and the association is still between the same nodes.
o Different sessions between the same two locators may result in o Different associations between the same two locators may result in
connections to different nodes, if the implementation no longer connections to different nodes, if the implementation no longer
remembers which identifier the peer had in an earlier session. remembers which identifier the peer had in an earlier association.
This is possible when the peer's locator has changed for This is possible when the peer's locator has changed for
legitimate reasons or when an attacker pretends to be a node that legitimate reasons or when an attacker pretends to be a node that
has the peer's locator. Therefore, when using opportunistic mode, has the peer's locator. Therefore, when using opportunistic mode,
HIP implementations MUST NOT place any expectation that the peer's HIP implementations MUST NOT place any expectation that the peer's
HI returned in the R1 message matches any HI previously seen from HI returned in the R1 message matches any HI previously seen from
that address. that address.
If the HIP implementation and application do not have the same If the HIP implementation and application do not have the same
understanding of what constitutes a session, this may even happen understanding of what constitutes an association, this may even
within the same session. For instance, an implementation may not happen within the same association. For instance, an
know when HIP state can be purged for UDP-based applications. implementation may not know when HIP state can be purged for UDP-
based applications.
o As with all HIP base exchanges, the handling of locator-based or
interface-based policy is unclear for HIP in opportunistic mode.
An application may create a connection to a specific locator
because the application has knowledge of the security properties
along the network to that locator. If one of the nodes moves and
the locators are updated, these security properties may not be
maintained. Depending on the security policy of the application,
this may be a problem. This is an area of ongoing study. As an
example, there is work to create an API that applications can use
to specify their security requirements in a similar context
[I-D.ietf-btns-c-api].
In addition, the following security considerations apply. The In addition, the following security considerations apply. The
generation counter mechanism will be less efficient in protecting generation counter mechanism will be less efficient in protecting
against replays of the R1 packet, given that the Responder can choose against replays of the R1 packet, given that the Responder can choose
a replay that uses an arbitrary HI, not just the one given in the I1 a replay that uses an arbitrary HI, not just the one given in the I1
packet. packet.
More importantly, the opportunistic exchange is vulnerable to man-in- More importantly, the opportunistic exchange is vulnerable to man-in-
the-middle attacks, because the Initiator does not have any public the-middle attacks, because the Initiator does not have any public
key information about the peer. To assess the impacts of this key information about the peer. To assess the impacts of this
vulnerability, we compare it to vulnerabilities in current, non-HIP- vulnerability, we compare it to vulnerabilities in current, non-HIP-
capable communications. capable communications.
An attacker on the path between the two peers can insert itself as a An attacker on the path between the two peers can insert itself as a
man-in-the-middle by providing its own identifier to the Initiator man-in-the-middle by providing its own identifier to the Initiator
and then initiating another HIP session towards the Responder. For and then initiating another HIP association towards the Responder.
this to be possible, the Initiator must employ opportunistic mode, For this to be possible, the Initiator must employ opportunistic
and the Responder must be configured to accept a connection from any mode, and the Responder must be configured to accept a connection
HIP-enabled node. from any HIP-enabled node.
An attacker outside the path will be unable to do so, given that it An attacker outside the path will be unable to do so, given that it
cannot respond to the messages in the base exchange. cannot respond to the messages in the base exchange.
These security properties are characteristic also of communications These security properties are characteristic also of communications
in the current Internet. A client contacting a server without in the current Internet. A client contacting a server without
employing end-to-end security may find itself talking to the server employing end-to-end security may find itself talking to the server
via a man-in-the-middle, assuming again that the server is willing to via a man-in-the-middle, assuming again that the server is willing to
talk to anyone. talk to anyone.
skipping to change at page 25, line 45 skipping to change at page 25, line 15
association is established. association is established.
The system with data to send has a HIP association, but the The system with data to send has a HIP association, but the
receiver does not. receiver does not.
The system sends data on the outbound user data security The system sends data on the outbound user data security
association. The receiver 'detects' the situation when it association. The receiver 'detects' the situation when it
receives a user data packet that it cannot match to any HIP receives a user data packet that it cannot match to any HIP
association. The receiving host MUST discard this packet. association. The receiving host MUST discard this packet.
Optionally, the receiving host MAY send an ICMP packet, with The receiving host SHOULD send an ICMP packet, with the type
the type Parameter Problem, to inform the sender that the HIP Parameter Problem, to inform the sender that the HIP
association does not exist (see Section 5.4), and it MAY association does not exist (see Section 5.4), and it MAY
initiate a new HIP BEX. However, responding with these initiate a new HIP BEX. However, responding with these
optional mechanisms is implementation or policy dependent. optional mechanisms is implementation or policy dependent. If
the sending application doesn't expect a response, the system
could possibly send a large number of packets in this state, so
for this reason, the sending of one or more ICMP packets is
RECOMMENDED. However, any such responses MUST be rate-limited
to prevent abuse (see Section 5.4).
4.4. HIP State Machine 4.4. HIP State Machine
The HIP protocol itself has little state. In the HIP base exchange, The HIP protocol itself has little state. In the HIP base exchange,
there is an Initiator and a Responder. Once the security there is an Initiator and a Responder. Once the security
associations (SAs) are established, this distinction is lost. If the associations (SAs) are established, this distinction is lost. If the
HIP state needs to be re-established, the controlling parameters are HIP state needs to be re-established, the controlling parameters are
which peer still has state and which has a datagram to send to its which peer still has state and which has a datagram to send to its
peer. The following state machine attempts to capture these peer. The following state machine attempts to capture these
processes. processes.
skipping to change at page 26, line 45 skipping to change at page 26, line 19
machine focuses on the HIP I1, R1, I2, and R2 packets only. New machine focuses on the HIP I1, R1, I2, and R2 packets only. New
states and state transitions may be introduced by mechanisms in other states and state transitions may be introduced by mechanisms in other
specifications (such as mobility and multihoming). specifications (such as mobility and multihoming).
4.4.1. State Machine Terminology 4.4.1. State Machine Terminology
Unused Association Lifetime (UAL): Implementation-specific time for Unused Association Lifetime (UAL): Implementation-specific time for
which, if no packet is sent or received for this time interval, a which, if no packet is sent or received for this time interval, a
host MAY begin to tear down an active HIP association. host MAY begin to tear down an active HIP association.
Maximum Segment Lifetime (MSL): Maximum time that a TCP segment is Maximum Segment Lifetime (MSL): Maximum time that a HIP packet is
expected to spend in the network. expected to spend in the network. A default value of 2 minutes
has been borrowed from [RFC0793] because it is a prevailing
assumption for packet lifetimes.
Exchange Complete (EC): Time that the host spends at the R2-SENT Exchange Complete (EC): Time that the host spends at the R2-SENT
state before it moves to the ESTABLISHED state. The time is n * state before it moves to the ESTABLISHED state. The time is n *
I2 retransmission timeout, where n is about I2_RETRIES_MAX. I2 retransmission timeout, where n is about I2_RETRIES_MAX.
Receive ANYOTHER: Any received packet for which no state Receive ANYOTHER: Any received packet for which no state
transitions or processing rules are defined for a given state. transitions or processing rules are defined for a given state.
4.4.2. HIP States 4.4.2. HIP States
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| State | Explanation | | State | Explanation |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| UNASSOCIATED | State machine start | | UNASSOCIATED | State machine start |
| | | | | |
| I1-SENT | Initiating base exchange | | I1-SENT | Initiating base exchange |
| | | | | |
| I2-SENT | Waiting to complete base exchange | | I2-SENT | Waiting to complete base exchange |
| | | | | |
| R2-SENT | Waiting to complete base exchange | | R2-SENT | Waiting to complete base exchange |
skipping to change at page 28, line 6 skipping to change at page 28, line 6
| CLOSED | HIP association closed, no data can be sent | | CLOSED | HIP association closed, no data can be sent |
| | | | | |
| E-FAILED | HIP base exchange failed | | E-FAILED | HIP base exchange failed |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 1: HIP States Table 1: HIP States
4.4.3. HIP State Processes 4.4.3. HIP State Processes
System behavior in state UNASSOCIATED, Table 2. System behavior in state UNASSOCIATED, Table 2.
+---------------------+---------------------------------------------+ +----------------------------+--------------------------------------+
| Trigger | Action | | Trigger | Action |
+---------------------+---------------------------------------------+ +----------------------------+--------------------------------------+
| User data to send, | Send I1 and go to I1-SENT | | User data to send, | Send I1 and go to I1-SENT |
| requiring a new HIP | | | requiring a new HIP | |
| association | | | association | |
| | | | | |
| Receive I1 | Send R1 and stay at UNASSOCIATED | | Receive I1 | Send R1 and stay at UNASSOCIATED |
| | | | | |
| Receive I2, process | If successful, send R2 and go to R2-SENT | | Receive I2, process | If successful, send R2 and go to |
| | | | | R2-SENT |
| | If fail, stay at UNASSOCIATED | | | |
| | | | | If fail, stay at UNASSOCIATED |
| Receive user data | Optionally send ICMP as defined in | | | |
| for an unknown HIP | Section 5.4 and stay at UNASSOCIATED | | Receive user data for an | Optionally send ICMP as defined in |
| association | | | unknown HIP association | Section 5.4 and stay at UNASSOCIATED |
| | | | | |
| Receive CLOSE | Optionally send ICMP Parameter Problem and | | Receive CLOSE | Optionally send ICMP Parameter |
| | stay at UNASSOCIATED | | | Problem and stay at UNASSOCIATED |
| | | | | |
| Receive ANYOTHER | Drop and stay at UNASSOCIATED | | Receive ANYOTHER | Drop and stay at UNASSOCIATED |
+---------------------+---------------------------------------------+ +----------------------------+--------------------------------------+
Table 2: UNASSOCIATED - Start state Table 2: UNASSOCIATED - Start state
System behavior in state I1-SENT, Table 3. System behavior in state I1-SENT, Table 3.
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Trigger | Action | | Trigger | Action |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Receive I1 from | If the local HIT is smaller than the peer | | Receive I1 from | If the local HIT is smaller than the peer |
| Responder | HIT, drop I1 and stay at I1-SENT (see | | Responder | HIT, drop I1 and stay at I1-SENT (see |
skipping to change at page 29, line 31 skipping to change at page 29, line 31
| Receive R1, process | If the HIT Suite of the local HIT is not | | Receive R1, process | If the HIT Suite of the local HIT is not |
| | supported by the peer, select supported | | | supported by the peer, select supported |
| | local HIT, send I1 and stay at I1-SENT | | | local HIT, send I1 and stay at I1-SENT |
| | | | | |
| | If successful, send I2 and go to I2-SENT | | | If successful, send I2 and go to I2-SENT |
| | | | | |
| | If fail, stay at I1-SENT | | | If fail, stay at I1-SENT |
| | | | | |
| Receive ANYOTHER | Drop and stay at I1-SENT | | Receive ANYOTHER | Drop and stay at I1-SENT |
| | | | | |
| Timeout | Increment timeout counter | | Timeout | Increment trial counter |
| | | | | |
| | If counter is less than I1_RETRIES_MAX, | | | If counter is less than I1_RETRIES_MAX, |
| | send I1 and stay at I1-SENT | | | send I1 and stay at I1-SENT |
| | | | | |
| | If counter is greater than I1_RETRIES_MAX, | | | If counter is greater than I1_RETRIES_MAX, |
| | go to E-FAILED | | | go to E-FAILED |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 3: I1-SENT - Initiating the HIP Base Exchange Table 3: I1-SENT - Initiating the HIP base exchange
System behavior in state I2-SENT, Table 4. System behavior in state I2-SENT, Table 4.
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Trigger | Action | | Trigger | Action |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Receive I1 | Send R1 and stay at I2-SENT | | Receive I1 | Send R1 and stay at I2-SENT |
| | | | | |
| Receive R1, process | If successful, send I2 and stay at I2-SENT | | Receive R1, process | If successful, send I2 and stay at I2-SENT |
| | | | | |
skipping to change at page 30, line 35 skipping to change at page 30, line 35
| | | | | |
| | If fail, stay at I2-SENT | | | If fail, stay at I2-SENT |
| | | | | |
| Receive CLOSE, | If successful, send CLOSE_ACK and go to | | Receive CLOSE, | If successful, send CLOSE_ACK and go to |
| process | CLOSED | | process | CLOSED |
| | | | | |
| | If fail, stay at I2-SENT | | | If fail, stay at I2-SENT |
| | | | | |
| Receive ANYOTHER | Drop and stay at I2-SENT | | Receive ANYOTHER | Drop and stay at I2-SENT |
| | | | | |
| Timeout | Increment timeout counter | | Timeout | Increment trial counter |
| | | | | |
| | If counter is less than I2_RETRIES_MAX, | | | If counter is less than I2_RETRIES_MAX, |
| | send I2 and stay at I2-SENT | | | send I2 and stay at I2-SENT |
| | | | | |
| | If counter is greater than I2_RETRIES_MAX, | | | If counter is greater than I2_RETRIES_MAX, |
| | go to E-FAILED | | | go to E-FAILED |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 4: I2-SENT - Waiting to finish the HIP Base Exchange Table 4: I2-SENT - Waiting to finish the HIP base exchange
System behavior in state R2-SENT, Table 5. System behavior in state R2-SENT, Table 5.
+---------------------+---------------------------------------------+ +------------------------+------------------------------------------+
| Trigger | Action | | Trigger | Action |
+---------------------+---------------------------------------------+ +------------------------+------------------------------------------+
| Receive I1 | Send R1 and stay at R2-SENT | | Receive I1 | Send R1 and stay at R2-SENT |
| | | | | |
| Receive I2, process | If successful, send R2 and stay at R2-SENT | | Receive I2, process | If successful, send R2 and stay at |
| | | | | R2-SENT |
| | If fail, stay at R2-SENT | | | |
| | | | | If fail, stay at R2-SENT |
| Receive R1 | Drop and stay at R2-SENT | | | |
| | | | Receive R1 | Drop and stay at R2-SENT |
| Receive R2 | Drop and stay at R2-SENT | | | |
| | | | Receive R2 | Drop and stay at R2-SENT |
| Receive data or | Move to ESTABLISHED | | | |
| UPDATE | | | Receive data or UPDATE | Move to ESTABLISHED |
| | | | | |
| Exchange Complete | Move to ESTABLISHED | | Exchange Complete | Move to ESTABLISHED |
| Timeout | | | Timeout | |
| | | | | |
| Receive CLOSE, | If successful, send CLOSE_ACK and go to | | Receive CLOSE, process | If successful, send CLOSE_ACK and go to |
| process | CLOSED | | | CLOSED |
| | | | | |
| | If fail, stay at ESTABLISHED | | | If fail, stay at ESTABLISHED |
| | | | | |
| Receive CLOSE_ACK | Drop and stay at R2-SENT | | Receive CLOSE_ACK | Drop and stay at R2-SENT |
| | | | | |
| Receive NOTIFY | Process and stay at R2-SENT | | Receive NOTIFY | Process and stay at R2-SENT |
+---------------------+---------------------------------------------+ +------------------------+------------------------------------------+
Table 5: R2-SENT - Waiting to finish HIP Table 5: R2-SENT - Waiting to finish HIP
System behavior in state ESTABLISHED, Table 6. System behavior in state ESTABLISHED, Table 6.
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Trigger | Action | | Trigger | Action |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Receive I1 | Send R1 and stay at ESTABLISHED | | Receive I1 | Send R1 and stay at ESTABLISHED |
| | | | | |
skipping to change at page 33, line 7 skipping to change at page 33, line 7
| | | | | |
| Receive CLOSE_ACK | Drop and stay at ESTABLISHED | | Receive CLOSE_ACK | Drop and stay at ESTABLISHED |
| | | | | |
| Receive NOTIFY | Process and stay at ESTABLISHED | | Receive NOTIFY | Process and stay at ESTABLISHED |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 6: ESTABLISHED - HIP association established Table 6: ESTABLISHED - HIP association established
System behavior in state CLOSING, Table 7. System behavior in state CLOSING, Table 7.
+---------------------+---------------------------------------------+ +----------------------------+--------------------------------------+
| Trigger | Action | | Trigger | Action |
+---------------------+---------------------------------------------+ +----------------------------+--------------------------------------+
| User data to send, | Send I1 and stay at CLOSING | | User data to send, | Send I1 and stay at CLOSING |
| requires the | | | requires the creation of | |
| creation of another | | | another incarnation of the | |
| incarnation of the | | | HIP association | |
| HIP association | | | | |
| | | | Receive I1 | Send R1 and stay at CLOSING |
| Receive I1 | Send R1 and stay at CLOSING | | | |
| | | | Receive I2, process | If successful, send R2 and go to |
| Receive I2, process | If successful, send R2 and go to R2-SENT | | | R2-SENT |
| | | | | |
| | If fail, stay at CLOSING | | | If fail, stay at CLOSING |
| | | | | |
| Receive R1, process | If successful, send I2 and go to I2-SENT | | Receive R1, process | If successful, send I2 and go to |
| | | | | I2-SENT |
| | If fail, stay at CLOSING | | | |
| | | | | If fail, stay at CLOSING |
| Receive CLOSE, | If successful, send CLOSE_ACK, discard | | | |
| process | state and go to CLOSED | | Receive CLOSE, process | If successful, send CLOSE_ACK, |
| | | | | discard state and go to CLOSED |
| | If fail, stay at CLOSING | | | |
| | | | | If fail, stay at CLOSING |
| Receive CLOSE_ACK, | If successful, discard state and go to | | | |
| process | UNASSOCIATED | | Receive CLOSE_ACK, process | If successful, discard state and go |
| | | | | to UNASSOCIATED |
| | If fail, stay at CLOSING | | | |
| | | | | If fail, stay at CLOSING |
| Receive ANYOTHER | Drop and stay at CLOSING | | | |
| | | | Receive ANYOTHER | Drop and stay at CLOSING |
| Timeout | Increment timeout sum and reset timer. If | | | |
| | timeout sum is less than UAL+MSL minutes, | | Timeout | Increment timeout sum and reset |
| | retransmit CLOSE and stay at CLOSING | | | timer. If timeout sum is less than |
| | | | | UAL+MSL minutes, retransmit CLOSE |
| | If timeout sum is greater than UAL+MSL | | | and stay at CLOSING |
| | minutes, go to UNASSOCIATED | | | |
+---------------------+---------------------------------------------+ | | If timeout sum is greater than |
| | UAL+MSL minutes, go to UNASSOCIATED |
+----------------------------+--------------------------------------+
Table 7: CLOSING - HIP association has not been used for UAL minutes Table 7: CLOSING - HIP association has not been used for UAL minutes
System behavior in state CLOSED, Table 8. System behavior in state CLOSED, Table 8.
+---------------------+---------------------------------------------+ +----------------------------------------+--------------------------+
| Trigger | Action | | Trigger | Action |
+---------------------+---------------------------------------------+ +----------------------------------------+--------------------------+
| Datagram to send, | Send I1, and stay at CLOSED | | Datagram to send, requires the | Send I1, and stay at |
| requires the | | | creation of another incarnation of the | CLOSED |
| creation of another | | | HIP association | |
| incarnation of the | | | | |
| HIP association | | | Receive I1 | Send R1 and stay at |
| | | | | CLOSED |
| Receive I1 | Send R1 and stay at CLOSED | | | |
| | | | Receive I2, process | If successful, send R2 |
| Receive I2, process | If successful, send R2 and go to R2-SENT | | | and go to R2-SENT |
| | | | | |
| | If fail, stay at CLOSED | | | If fail, stay at CLOSED |
| | | | | |
| Receive R1, process | If successful, send I2 and go to I2-SENT | | Receive R1, process | If successful, send I2 |
| | | | | and go to I2-SENT |
| | If fail, stay at CLOSED | | | |
| | | | | If fail, stay at CLOSED |
| Receive CLOSE, | If successful, send CLOSE_ACK, stay at | | | |
| process | CLOSED | | Receive CLOSE, process | If successful, send |
| | | | | CLOSE_ACK, stay at |
| | If fail, stay at CLOSED | | | CLOSED |
| | | | | |
| Receive CLOSE_ACK, | If successful, discard state and go to | | | If fail, stay at CLOSED |
| process | UNASSOCIATED | | | |
| | | | Receive CLOSE_ACK, process | If successful, discard |
| | If fail, stay at CLOSED | | | state and go to |
| | | | | UNASSOCIATED |
| Receive ANYOTHER | Drop and stay at CLOSED | | | |
| | | | | If fail, stay at CLOSED |
| Timeout (UAL+2MSL) | Discard state, and go to UNASSOCIATED | | | |
+---------------------+---------------------------------------------+ | Receive ANYOTHER | Drop and stay at CLOSED |
| | |
| Timeout (UAL+2MSL) | Discard state, and go to |
| | UNASSOCIATED |
+----------------------------------------+--------------------------+
Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary
System behavior in state E-FAILED, Table 9. System behavior in state E-FAILED, Table 9.
+-------------------------+-----------------------------------------+ +-------------------------+-----------------------------------------+
| Trigger | Action | | Trigger | Action |
+-------------------------+-----------------------------------------+ +-------------------------+-----------------------------------------+
| Wait for | Go to UNASSOCIATED. Re-negotiation is | | Wait for | Go to UNASSOCIATED. Re-negotiation is |
| implementation-specific | possible after moving to UNASSOCIATED | | implementation-specific | possible after moving to UNASSOCIATED |
skipping to change at page 36, line 10 skipping to change at page 36, line 10
The following diagram (Figure 2) shows the major state transitions. The following diagram (Figure 2) shows the major state transitions.
Transitions based on received packets implicitly assume that the Transitions based on received packets implicitly assume that the
packets are successfully authenticated or processed. packets are successfully authenticated or processed.
+--+ +----------------------------+ +--+ +----------------------------+
recv I1, send R1 | | | | recv I1, send R1 | | | |
| v v | | v v |
+--------------+ recv I2, send R2 | +--------------+ recv I2, send R2 |
+----------------| UNASSOCIATED |----------------+ | +----------------| UNASSOCIATED |----------------+ |
datagram| +--+ +--------------+ | | datagram | +--+ +--------------+ | |
to send,| | | Alg. not supported, | | to send, | | | Alg. not supported, | |
send I1| | | send I1 | | send I1 | | | send I1 | |
v | v | | . v | v | |
+---------+ recv I2, send R2 | | . +---------+ recv I2, send R2 | |
+---->| I1-SENT |--------------------------------------+ | | +---->| I1-SENT |--------------------------------------+ | |
| +---------+ +----------------------+ | | | | +---------+ +----------------------+ | | |
| | recv R2, | recv I2, send R2 | | | | | | recv R2, | recv I2, send R2 | | | |
| v send I2 | v v v | | v send I2 | v v v |
| +---------+ | +---------+ | | +---------+ | +---------+ |
| +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ | | +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ |
| | +---------+ | +---------+ | | | | +---------+ | +---------+ | |
| | | |recv R2 | data or| | | | | | |recv R2 | data or| | |
| |recv R1, | | | EC timeout| | | | |recv R1, | | | EC timeout| | |
| |send I2 +--|-----------------+ | receive I2,| | | |send I2 +--|-----------------+ | receive I2,| |
skipping to change at page 37, line 33 skipping to change at page 37, line 33
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]. The transport format to format for HIP [I-D.ietf-hip-rfc5202-bis]. The transport format to
be chosen is negotiated in the base exchange. The Responder be chosen is negotiated in the base exchange. The Responder
expresses its preference of the transport format in the expresses its preference of the transport format in the
TRANSPORT_FORMAT_LIST in the R1 packet and the Initiator selects one TRANSPORT_FORMAT_LIST in the R1 packet and the Initiator selects one
transform and adds the respective HIP parameter to the I2 packet. transport format 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 40, line 13 skipping to change at page 40, line 13
The HIT fields are always 128 bits (16 bytes) long. The HIT fields are always 128 bits (16 bytes) long.
5.1.1. Checksum 5.1.1. Checksum
Since the checksum covers the source and destination addresses in the Since the checksum covers the source and destination addresses in the
IP header, it MUST be recomputed on HIP-aware NAT devices. IP header, it MUST be recomputed on HIP-aware NAT devices.
If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460] If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460]
contains the source and destination IPv6 addresses, HIP packet length contains the source and destination IPv6 addresses, HIP packet length
in the pseudo-header length field, a zero field, and the HIP protocol in the pseudo-header length field, a zero field, and the HIP protocol
number (see Section 4) in the Next Header field. The length field is number (see Section 5.1) in the Next Header field. The length field
in bytes and can be calculated from the HIP header length field: (HIP is in bytes and can be calculated from the HIP header length field:
Header Length + 1) * 8.
(HIP Header Length + 1) * 8.
In case of using IPv4, the IPv4 UDP pseudo-header format [RFC0768] is In case of using IPv4, the IPv4 UDP pseudo-header format [RFC0768] is
used. In the pseudo-header, the source and destination addresses are used. In the pseudo-header, the source and destination addresses are
those used in the IP header, the zero field is obviously zero, the those used in the IP header, the zero field is obviously zero, the
protocol is the HIP protocol number (see Section 4), and the length protocol is the HIP protocol number (see Section 4), and the length
is calculated as in the IPv6 case. is calculated as in the IPv6 case.
5.1.2. HIP Controls 5.1.2. HIP Controls
The HIP Controls field conveys information about the structure of the The HIP Controls field conveys information about the structure of the
skipping to change at page 40, line 52 skipping to change at page 41, line 4
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
to be implemented in IPv6. In IPv6 networks, the minimum MTU is to be implemented in IPv6. In IPv6 networks, the minimum MTU is
larger, 1280 bytes, than in IPv4 networks. The larger MTU size is larger, 1280 bytes, than in IPv4 networks. The larger MTU size is
usually sufficient for most HIP packets, and therefore fragment usually sufficient for most HIP packets, and therefore fragment
generation may not be needed. If a host expects to send HIP packets generation may not be needed. If it is expected that a host will
that are larger than the minimum IPv6 MTU, it MUST implement fragment send HIP packets that are larger than the minimum IPv6 MTU, the
generation even for IPv6. implementation MUST implement fragment generation even for IPv6.
In IPv4 networks, HIP packets may encounter low MTUs along their In IPv4 networks, HIP packets may encounter low MTUs along their
routed path. Since basic HIP, as defined in this document, does not routed path. Since basic HIP, as defined in this document, does not
provide a mechanism to use multiple IP datagrams for a single HIP provide a mechanism to use multiple IP datagrams for a single HIP
packet, support for path MTU discovery does not bring any value to packet, support for path MTU discovery does not bring any value to
HIP in IPv4 networks. HIP-aware NAT devices SHOULD perform IPv4 HIP in IPv4 networks. HIP-aware NAT devices SHOULD perform IPv4
reassembly/fragmentation for HIP control packets. reassembly/fragmentation for HIP packets.
All HIP implementations have to be careful while employing a All HIP implementations have to be careful while employing a
reassembly algorithm so that the algorithm is sufficiently resistant reassembly algorithm so that the algorithm is sufficiently resistant
to DoS attacks. to DoS attacks.
Certificate chains can cause the packet to be fragmented and Certificate chains can cause the packet to be fragmented and
fragmentation can open implementations to denial-of-service attacks fragmentation can open implementations to denial-of-service attacks
[KAU03]. "Hash and URL" schemes as defined in [RFC6253] for HIP [KAU03]. "Hash and URL" schemes as defined in [RFC6253] for HIP
version 1 may be used to avoid fragmentation and mitigate resulting version 1 may be used to avoid fragmentation and mitigate resulting
DoS attacks. DoS attacks.
skipping to change at page 43, line 27 skipping to change at page 43, line 17
| | | numbers | | | | | numbers | |
| | | | | | | | | |
| HIP_MAC | 61505 | variable | HMAC-based message | | HIP_MAC | 61505 | variable | HMAC-based message |
| | | | authentication code, | | | | | authentication code, |
| | | | with key material | | | | | with key material |
| | | | from KEYMAT | | | | | from KEYMAT |
| | | | | | | | | |
| HIP_MAC_2 | 61569 | variable | HMAC based message | | HIP_MAC_2 | 61569 | variable | HMAC based message |
| | | | authentication code, | | | | | authentication code, |
| | | | with key material | | | | | with key material |
| | | | from KEYMAT. Unlike | | | | | from KEYMAT. Unlike |
| | | | HIP_MAC, the HOST_ID | | | | | HIP_MAC, the HOST_ID |
| | | | parameter is | | | | | parameter is |
| | | | included in | | | | | included in |
| | | | HIP_MAC_2 | | | | | HIP_MAC_2 |
| | | | calculation. | | | | | calculation. |
| | | | | | | | | |
| HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 | | HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 |
| | | | packet | | | | | packet |
| | | | | | | | | |
| HIP_SIGNATURE | 61697 | variable | Signature of the | | HIP_SIGNATURE | 61697 | variable | Signature of the |
skipping to change at page 44, line 11 skipping to change at page 44, line 8
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 formats | | 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 |
| | | | | |
| 61440 - 64443 | Signatures and (signed) MACs | | 61440 - 64443 | Signatures and (signed) MACs |
| | | | | |
| 62464 - 63487 | Parameters that are neither signed nor MACed | | 62464 - 63487 | Parameters that are neither signed nor MACed |
| | | | | |
| 63488 - 64511 | Rendezvous and relaying | | 63488 - 64511 | Rendezvous and relaying |
skipping to change at page 47, line 30 skipping to change at page 47, line 27
R1 generation R1 generation
counter The current generation of valid puzzles counter The current generation of valid puzzles
The R1_COUNTER parameter contains a 64-bit unsigned integer in The R1_COUNTER parameter contains a 64-bit unsigned integer in
network-byte order, indicating the current generation of valid network-byte order, indicating the current generation of valid
puzzles. The sender SHOULD increment this counter periodically. It puzzles. The sender SHOULD increment this counter periodically. It
is RECOMMENDED that the counter value is incremented at least as is RECOMMENDED that the counter value is incremented at least as
often as old PUZZLE values are deprecated so that SOLUTIONs to them often as old PUZZLE values are deprecated so that SOLUTIONs to them
are no longer accepted. are no longer accepted.
Support for the R1_COUNTER parameter is mandatory. It SHOULD be Support for the R1_COUNTER parameter is mandatory although its
included in the R1 (in which case, it is covered by the signature), inclusion in the R1 packet is optional. It SHOULD be included in the
and if present in the R1, it MUST be echoed (including the Reserved R1 (in which case, it is covered by the signature), and if present in
field verbatim) by the Initiator in the I2 packet. the R1, it MUST be echoed (including the Reserved field verbatim) by
the Initiator in the I2 packet.
5.2.4. PUZZLE 5.2.4. PUZZLE
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #K, 1 byte | Lifetime | Opaque, 2 bytes | | #K, 1 byte | Lifetime | Opaque, 2 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random #I, RHASH_len/8 bytes | | Random #I, RHASH_len/8 bytes |
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 48, line 29 skipping to change at page 48, line 26
Length 4 + RHASH_len / 8 Length 4 + RHASH_len / 8
#K #K is the number of verified bits #K #K is the number of verified bits
Lifetime puzzle lifetime 2^(value-32) seconds Lifetime puzzle lifetime 2^(value-32) seconds
Opaque data set by the Responder, indexing the puzzle Opaque data set by the Responder, indexing the puzzle
Random #I random number of size RHASH_len bits Random #I random number of size RHASH_len bits
Random #I is represented as a n-bit integer (where n is RHASH_len), Random #I is represented as a n-bit integer (where n is RHASH_len),
#K and Lifetime as 8-bit integers, all in network byte order. #K and Lifetime as 8-bit integers, all in network byte order.
The PUZZLE parameter contains the puzzle difficulty #K and a n-bit The PUZZLE parameter contains the puzzle difficulty #K and a n-bit
random integer #I. The Puzzle Lifetime indicates the time during random integer #I. The Puzzle Lifetime indicates the time during
which the puzzle solution is valid, and sets a time limit that should which the puzzle solution is valid, and sets a time limit that should
not be exceeded by the Initiator while it attempts to solve the not be exceeded by the Initiator while it attempts to solve the
puzzle. The lifetime is indicated as a power of 2 using the formula puzzle. The lifetime is indicated as a power of 2 using the formula
2^(Lifetime-32) seconds. A puzzle MAY be augmented with an 2^(Lifetime-32) seconds. A puzzle MAY be augmented with an
ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in
the R1; the contents of the echo request are then echoed back in the the R1; the contents of the echo request are then echoed back in the
ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED parameter, ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED parameter,
allowing the Responder to use the included information as a part of allowing the Responder to use the included information as a part of
its puzzle processing. its puzzle processing.
skipping to change at page 49, line 6 skipping to change at page 49, line 4
ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in
the R1; the contents of the echo request are then echoed back in the the R1; the contents of the echo request are then echoed back in the
ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED parameter, ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED parameter,
allowing the Responder to use the included information as a part of allowing the Responder to use the included information as a part of
its puzzle processing. its puzzle processing.
The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2
parameter. parameter.
5.2.5. SOLUTION 5.2.5. SOLUTION
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #K, 1 byte | Reserved | Opaque, 2 bytes | | #K, 1 byte | Reserved | Opaque, 2 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random #I, n bytes | | Random #I, n bytes |
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Puzzle solution #J, RHASH_len/8 bytes | | Puzzle solution #J, RHASH_len/8 bytes |
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 321 Type 321
Length 4 + RHASH_len /4 Length 4 + RHASH_len /4
skipping to change at page 50, line 19 skipping to change at page 50, line 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4| | DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH GROUP ID #n| Padding | | DH GROUP ID #n| Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 511 Type 511
Length number of DH Group IDs Length number of DH Group IDs
DH GROUP ID defines a DH GROUP ID supported by the host. DH GROUP ID identifies a DH GROUP 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. The list of define DH Group IDs in the host. The possible DH Group IDs are defined
DIFFIE_HELLMAN parameter. Each DH Group ID is one in the DIFFIE_HELLMAN parameter. Each DH Group ID
octet long. is one octet long.
The DH_GROUP_LIST parameter contains the list of supported DH Group 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 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 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 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 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 that are listed first are preferred over the DH Group IDs listed
later. The information in the DH_GROUP_LIST allows the Responder to later. The information in the DH_GROUP_LIST allows the Responder to
select the DH group preferred by itself and supported by the select the DH group preferred by itself and supported by the
Initiator. Based on the DH_GROUP_LIST in the R1 packet, the Initiator. Based on the DH_GROUP_LIST in the R1 packet, the
skipping to change at page 51, line 22 skipping to change at page 51, line 22
| Group ID | Public Value Length | Public Value / | Group ID | Public Value Length | Public Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding | / | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 513 Type 513
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
Padding Padding
Group ID defines values for p and g as well as the KDF Group ID identifies values for p and g as well as the KDF
Public Value length of the following Public Value in octets Public Value length of the following Public Value in octets
Length Length
Public Value the sender's public Diffie-Hellman key Public Value the sender's public Diffie-Hellman key
The following Group IDs have been defined: A single DIFFIE_HELLMAN parameter may be included in selected HIP
packets based on the DH Group ID selected (Section 5.2.6). The
following Group IDs have been defined:
Group KDF Value Group KDF Value
Reserved 0 Reserved 0
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
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 symmstric 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).
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
skipping to change at page 52, line 27 skipping to change at page 52, line 29
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cipher ID #1 | Cipher ID #2 | | Cipher ID #1 | Cipher ID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cipher ID #n | Padding | | Cipher ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 579 Type 579
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
Padding Padding
Cipher ID defines the cipher algorithm to be used for Cipher ID identifies the cipher algorithm to be used for
encrypting the contents of the ENCRYPTED parameter encrypting the contents of the ENCRYPTED parameter
The following Cipher IDs are defined: The following Cipher IDs are defined:
Suite ID Value Suite ID Value
RESERVED 0 RESERVED 0
NULL-ENCRYPT 1 ([RFC2410]) NULL-ENCRYPT 1 ([RFC2410])
AES-128-CBC 2 ([RFC3602]) AES-128-CBC 2 ([RFC3602])
DEPRECATED 3 DEPRECATED 3
AES-256-CBC 4 ([RFC3602]) AES-256-CBC 4 ([RFC3602])
The sender of a HIP_CIPHER parameter MUST make sure that there are no The sender of a HIP_CIPHER parameter MUST make sure that there are no
more than six (6) Cipher IDs in one HIP_CIPHER parameter. more than six (6) Cipher IDs in one HIP_CIPHER parameter.
Conversely, a recipient MUST be prepared to handle received transport Conversely, a recipient MUST be prepared to handle received transport
parameters that contain more than six Cipher IDs by accepting the parameters that contain more than six Cipher IDs by accepting the
first six Cipher IDs and dropping the rest. The limited number of first six Cipher IDs and dropping the rest. The limited number of
transforms sets the maximum size of the HIP_CIPHER parameter. As the Cipher IDs sets the maximum size of the HIP_CIPHER parameter. As the
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 [RFC2410] is Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION [RFC2410] is
skipping to change at page 55, line 11 skipping to change at page 55, line 11
For hosts that implement ECDSA as algorithm the following ECC curves For hosts that implement ECDSA as algorithm the following ECC curves
are required: are required:
Algorithm Curve Values Algorithm Curve Values
ECDSA RESERVED 0 ECDSA RESERVED 0
ECDSA NIST P-256 1 [RFC4754] ECDSA NIST P-256 1 [RFC4754]
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 ECDSA_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.10. 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 HIT Suite IDs are supported
Responder. by the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID #1 | ID #2 | ID #3 | ID #4 | | ID #1 | ID #2 | ID #3 | ID #4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID #n | Padding | | ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 715 Type 715
Length number of HIT Suite IDs Length number of HIT Suite IDs
ID defines a HIT Suite ID supported by the host. ID identifies 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.9 and hash functions. signature algorithms as defined in Section 5.2.9 and hash functions.
skipping to change at page 56, line 40 skipping to change at page 56, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TF type #1 | TF type #2 / | TF type #1 | TF type #2 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ TF type #n | Padding | / TF type #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2049 Type 2049
Length 2x number of TF types Length 2x number of TF types
TF Type defines a transport format (TF) type supported by TF Type identifies a transport format (TF) type supported by
the host. The TF type numbers correspond to the HIP the host. The TF type numbers correspond to the HIP
parameter type numbers of the respective transform parameter type numbers of the respective transport
format
parameters. The list of TF types is ordered by parameters. The list of TF types is ordered by
preference of the sender preference of the sender
The TF type numbers index the respective HIP parameters for the The TF type numbers index the respective HIP parameters for the
transport formats in the type number range between 2050 to 4095. The transport formats in the type number range between 2050 to 4095. The
parameters and their use is defined in separate documents. parameters and their use are defined in separate documents.
Currently, the only transport format defined is IPsec ESP Currently, the only transport format defined is IPsec ESP
[I-D.ietf-hip-rfc5202-bis]. [I-D.ietf-hip-rfc5202-bis].
For each listed TF type, the sender of the parameter MUST include the For each listed TF type, the sender of the TRANSPORT_FORMAT_LIST
repective transport form parameter in the HIP packet. The TF type in parameter MUST include the respective transport format parameter in
the TRANSPORT_FORM_LIST MUST be ignored if no matching transport form the HIP packet. The receiver MUST ignore the TF type in the
parameter is present in the packet. TRANSPORT_FORMAT_LIST if no matching transport format parameter is
present in the packet.
5.2.12. HIP_MAC 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 57, line 43 skipping to change at page 57, line 44
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.13. 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 HI of the sender in the
sender while only the packet without HOST_ID of the sender is sent. form of a HOST_ID parameter when that parameter is not actually
The parameter structure is the same as in Section 5.2.12. The fields included in the packet. The parameter structure is the same as in
are: Section 5.2.12. The fields 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
parameter during the HMAC calculation. The checksum parameter during the HMAC calculation. The checksum
skipping to change at page 58, line 50 skipping to change at page 58, line 50
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.9. 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-
SHA-1, according to [RFC5702] in case of RSA/SHA-256, according to 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.15. 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
skipping to change at page 64, line 5 skipping to change at page 63, line 29
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
failed entirely. Unrecognized error types MUST be ignored except failed entirely. Unrecognized error types MUST be ignored except
that they SHOULD be logged. that they SHOULD be logged.
As currently defined, Notify Message Type values 1-10 are used for As currently defined, 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. informing about problems in parameters.
Notification Data in NOTIFICATION parameters with status Notify Notification Data in NOTIFICATION parameters where the Notify Message
Message Types MUST be ignored if not recognized. Type is in the status range MUST be ignored if not recognized.
Notify Message Types - Errors Value Notify Message Types - Errors Value
----------------------------- ----- ----------------------------- -----
UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1
Sent if the parameter type has the "critical" bit set and the Sent if the parameter type has the "critical" bit set and the
parameter type is not recognized. Notification Data contains the parameter type is not recognized. Notification Data contains the
two-octet parameter type. two-octet parameter type.
INVALID_SYNTAX 7 INVALID_SYNTAX 7
Indicates that the HIP message received was invalid because some Indicates that the HIP message received was invalid because some
type, length, or value was out of range or because the request type, length, or value was out of range or because the request
was otherwise malformed. To avoid a denial- of-service was otherwise malformed. To avoid a denial-of-service
attack using forged messages, this status may only be returned attack using forged messages, this status may only be returned
for packets whose HIP_MAC (if present) and SIGNATURE have been for packets whose HIP_MAC (if present) and SIGNATURE have been
verified. This status MUST be sent in response to any error not verified. This status MUST be sent in response to any error not
covered by one of the other status types, and SHOULD NOT contain covered by one of the other status types, and SHOULD NOT contain
details to avoid leaking information to someone probing a node. details to avoid leaking information to someone probing a node.
To aid debugging, more detailed error information SHOULD be To aid debugging, more detailed error information SHOULD be
written to a console or log. written to a console or log.
NO_DH_PROPOSAL_CHOSEN 14 NO_DH_PROPOSAL_CHOSEN 14
skipping to change at page 66, line 31 skipping to change at page 66, line 6
The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data
that the sender wants to get echoed back in the corresponding reply that the sender wants to get echoed back in the corresponding reply
packet. packet.
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 parameters. 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.21. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 68, line 35 skipping to change at page 68, line 11
The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used
for any purpose where a node wants to carry some state in a request for any purpose where a node wants to carry some state in a request
packet and get it back in a response packet. The packet and get it back in a response packet. The
ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE.
5.3. HIP Packets 5.3. HIP Packets
There are eight basic HIP packets (see Table 10). Four are for the There are eight basic HIP packets (see Table 10). Four are for the
HIP base exchange, one is for updating, one is for sending HIP base exchange, one is for updating, one is for sending
notifications, and two are for closing a HIP association. notifications, and two are for closing a HIP association. Support
for NOTIFY packet type is optional, but support for all other HIP
packet types listed below is mandatory.
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| Packet type | Packet name | | Packet type | Packet name |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| 1 | I1 - the HIP Initiator Packet | | 1 | I1 - the HIP Initiator Packet |
| | | | | |
| 2 | R1 - the HIP Responder Packet | | 2 | R1 - the HIP Responder Packet |
| | | | | |
| 3 | I2 - the Second HIP Initiator Packet | | 3 | I2 - the Second HIP Initiator Packet |
| | | | | |
| 4 | R2 - the Second HIP Responder Packet | | 4 | R2 - the Second HIP Responder Packet |
| | | | | |
| 16 | UPDATE - the HIP Update Packet | | 16 | UPDATE - the HIP Update Packet |
| | | | | |
| 17 | NOTIFY - the HIP Notify Packet | | 17 | NOTIFY - the HIP Notify Packet |
| | | | | |
| 18 | CLOSE - the HIP Association Closing Packet | | 18 | CLOSE - the HIP Association Closing Packet |
| | | | | |
| 19 | CLOSE_ACK - the HIP Closing Acknowledgment | | 19 | CLOSE_ACK - the HIP Closing Acknowledgment |
| | Packet | | | Packet |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
skipping to change at page 69, line 41 skipping to change at page 68, line 51
In addition to the base packets, other packet types may be defined In addition to the base packets, other packet types may be defined
later in separate specifications. For example, support for mobility later in separate specifications. For example, support for mobility
and multi-homing is not included in this specification. and multi-homing is not included in this specification.
See Notation (Section 2.2) for the notation used in the operations. See Notation (Section 2.2) for the notation used in the operations.
In the future, an optional upper-layer payload MAY follow the HIP In the future, an optional upper-layer payload MAY follow the HIP
header. The Next Header field in the header indicates if there is header. The Next Header field in the header indicates if there is
additional data following the HIP header. The HIP packet, however, additional data following the HIP header. The HIP packet, however,
MUST NOT be fragmented. This limits the size of the possible MUST NOT be fragmented into multiple extension headers by setting the
additional data in the packet. Next Header field in a HIP header to the HIP protocol number. This
limits the size of the possible additional data in the packet.
5.3.1. I1 - the HIP Initiator Packet 5.3.1. I1 - the HIP Initiator Packet
The HIP header values for the I1 packet: The HIP header values for the I1 packet:
Header: Header:
Packet Type = 1 Packet Type = 1
SRC HIT = Initiator's HIT SRC HIT = Initiator's HIT
DST HIT = Responder's HIT, or NULL DST HIT = Responder's HIT, or NULL
skipping to change at page 71, line 17 skipping to change at page 70, line 37
the R1 is a response to an I1. If the Responder has multiple HIs, the R1 is a response to an I1. If the Responder has multiple HIs,
the Responder's HIT used MUST match Initiator's request. If the the Responder's HIT used MUST match Initiator's request. If the
Initiator used opportunistic mode, the Responder may select freely Initiator used opportunistic mode, the Responder may select freely
among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8). among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8).
The R1 packet generation counter is used to determine the currently The R1 packet generation counter is used to determine the currently
valid generation of puzzles. The value is increased periodically, valid generation of puzzles. The value is increased periodically,
and it is RECOMMENDED that it is increased at least as often as and it is RECOMMENDED that it is increased at least as often as
solutions to old puzzles are no longer accepted. solutions to old puzzles are no longer accepted.
The Puzzle contains a Random #I and the difficulty #K. The The Puzzle contains a Random #I and the difficulty #K. The
difficulty #K indicates the number of lower-order bits, in the puzzle difficulty #K indicates the number of lower-order bits, in the puzzle
hash result, that must be zeros; see Section 4.1.2. The Random #I is hash result, that must be zeros; see Section 4.1.2. The Random #I is
not covered by the signature and must be zeroed during the signature not covered by the signature and must be zeroed during the signature
calculation, allowing the sender to select and set the #I into a calculation, allowing the sender to select and set the #I into a
precomputed R1 packet just prior sending it to the peer. precomputed R1 packet just prior sending it to the peer.
The Responder selects the Diffie-Hellman public value based on the The Responder selects the Diffie-Hellman public value based on the
Initiator's preference expressed in the DH_GROUP_LIST parameter in Initiator's preference expressed in the DH_GROUP_LIST parameter in
the I1 packet. The Responder sends back its own preference based on the I1 packet. The Responder sends back its own preference based on
which it chose the DH public value as DH_GROUP_LIST. This allows the which it chose the DH public value as DH_GROUP_LIST. This allows the
Initiator to determine whether its own DH_GROUP_LIST in the sent I1 Initiator to determine whether its own DH_GROUP_LIST in the sent I1
packet was manipulated by an attacker. packet was manipulated by an attacker.
The Diffie-Hellman public value is ephemeral, and values SHOULD NOT The Diffie-Hellman public value is ephemeral, and values SHOULD NOT
be reused across different HIP sessions. Once the Responder has be reused across different HIP associations. Once the Responder has
received a valid response to an R1 packet, that Diffie-Hellman value received a valid response to an R1 packet, that Diffie-Hellman value
SHOULD be deprecated. It is possible that the Responder has sent the SHOULD be deprecated. It is possible that the Responder has sent the
same Diffie-Hellman value to different hosts simultaneously in same Diffie-Hellman value to different hosts simultaneously in
corresponding R1 packets and those responses should also be accepted. corresponding R1 packets and those responses should also be accepted.
However, as a defense against I1 packet storms, an implementation MAY However, as a defense against I1 packet storms, an implementation MAY
propose, and re-use unless avoidable, the same Diffie-Hellman value propose, and re-use unless avoidable, the same Diffie-Hellman value
for a period of time, for example, 15 minutes. By using a small for a period of time, for example, 15 minutes. By using a small
number of different puzzles for a given Diffie-Hellman value, the R1 number of different puzzles for a given Diffie-Hellman value, the R1
packets can be precomputed and delivered as quickly as I1 packets packets can be precomputed and delivered as quickly as I1 packets
arrive. A scavenger process should clean up unused Diffie-Hellman arrive. A scavenger process should clean up unused Diffie-Hellman
skipping to change at page 72, line 46 skipping to change at page 72, line 18
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 5.2.21. Section Section 5.2.21.
The TRANSPORT_FORMAT_LIST parameter is an ordered list of the The TRANSPORT_FORMAT_LIST parameter is an ordered list of the
Responder's preferred and supported transport format types. The list Responder's preferred and supported transport format types. The list
allows the Initiator and the Responder to agree on a common type for allows the Initiator and the Responder to agree on a common type for
payload protection. This parameter is described in Section 5.2.11. payload protection. This parameter is described in Section 5.2.11.
The signature is calculated over the whole HIP packet as described in The signature is calculated over the whole HIP packet as described in
Section 5.2.15. 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.
skipping to change at page 73, line 49 skipping to change at page 73, line 21
packet into the I2 packet. packet into the I2 packet.
The Solution contains the Random #I from R1 and the computed #J. The The Solution contains the Random #I from R1 and the computed #J. The
low-order #K bits of the RHASH(I | ... | J) MUST be zero. low-order #K bits of the RHASH(I | ... | J) MUST be zero.
The Diffie-Hellman value is ephemeral. If precomputed, a scavenger The Diffie-Hellman value is ephemeral. If precomputed, a scavenger
process should clean up unused Diffie-Hellman values. The Responder process should clean up unused Diffie-Hellman values. The Responder
MAY re-use Diffie-Hellman values under some conditions as specified MAY re-use Diffie-Hellman values under some conditions as specified
in Section 5.3.2. in Section 5.3.2.
The HIP_CIPHER contains the single encryption transform selected by The HIP_CIPHER contains the single encryption suite selected by the
the Initiator, that it uses to encrypt the ENCRYPTED parameters. The Initiator, that it uses to encrypt the ENCRYPTED parameters. The
chosen cipher MUST correspond to one of the ciphers offered by the chosen cipher MUST correspond to one of the ciphers offered by the
Responder in the R1. All implementations MUST support AES [RFC3602]. Responder in the R1. All implementations MUST support AES [RFC3602].
The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption
algorithm. The keying material is derived from the Diffie-Hellman algorithm. The keying material is derived from the Diffie-Hellman
exchanged as defined in Section 6.5. exchanged as defined in Section 6.5.
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).
skipping to change at page 75, line 7 skipping to change at page 74, line 29
Responder's HOST_ID parameter concatenated with the HIP packet. The Responder's HOST_ID parameter concatenated with the HIP packet. The
HOST_ID parameter is removed after the HMAC calculation. The HOST_ID parameter is removed after the HMAC calculation. The
procedure is described in Section 6.4.1. procedure is described in Section 6.4.1.
The signature is calculated over the whole HIP packet. The signature is calculated over the whole HIP packet.
The Initiator MUST validate both the HIP_MAC and the signature. The Initiator MUST validate both the HIP_MAC and the signature.
5.3.5. UPDATE - the HIP Update Packet 5.3.5. UPDATE - the HIP Update Packet
Support for the UPDATE packet is MANDATORY.
The HIP header values for the UPDATE packet: The HIP header values for the UPDATE packet:
Header: Header:
Packet Type = 16 Packet Type = 16
SRC HIT = Sender's HIT SRC HIT = Sender's HIT
DST HIT = Recipient's HIT DST HIT = Recipient's HIT
IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) ) IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) )
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. Such UPDATE packets MUST NOT be acknowledged by a separate ACK parameter. Such UPDATE
containing only an ACK parameter do not require processing in packets containing only an ACK parameter do not require processing in
relative order to other UPDATE packets. An UPDATE packet without relative order to other UPDATE packets. An UPDATE packet without
either a SEQ or an ACK parameter is invalid; such unacknowledged either a SEQ or an ACK parameter is invalid; such unacknowledged
updates MUST instead use a NOTIFY packet. 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 parameter may contain the last two SEQ
received, for resilience against ACK loss. ACK values are not values received, for resilience against packet loss. ACK values are
cumulative; each received unique SEQ value requires at least one not 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 ACK parameters that are
are ignored. Hosts MUST implement the processing of ACKs with redundant are ignored. Hosts MUST implement the processing of ACK
multiple SEQ numbers even if they do not implement sending ACKs with parameters with multiple SEQ numbers even if they do not implement
multiple SEQ numbers. sending ACK parameters with multiple SEQ numbers.
The UPDATE packet may contain both a SEQ and an ACK parameter. In The UPDATE packet may contain both a SEQ and an ACK parameter. In
this case, the ACK is being piggybacked on an outgoing UPDATE. In this case, the ACK parameter is being piggybacked on an outgoing
general, UPDATEs carrying SEQ SHOULD be ACKed upon completion of the UPDATE. In general, UPDATEs carrying SEQ SHOULD be ACKed upon
processing of the UPDATE. A host MAY choose to hold the UPDATE completion of the processing of the UPDATE. A host MAY choose to
carrying ACK for a short period of time to allow for the possibility hold the UPDATE carrying an ACK parameter for a short period of time
of piggybacking the ACK parameter, in a manner similar to TCP delayed to allow for the possibility of piggybacking the ACK parameter, in a
acknowledgments. manner similar to TCP delayed acknowledgments.
A sender MAY choose to forgo reliable transmission of a particular A sender MAY choose to forego reliable transmission of a particular
UPDATE (e.g., it becomes overcome by events). The semantics are such UPDATE (e.g., it becomes overcome by events). The semantics are such
that the receiver MUST acknowledge the UPDATE, but the sender MAY that the receiver MUST acknowledge the UPDATE, but the sender MAY
choose to not care about receiving the ACK. choose to not care about receiving the ACK parameter.
UPDATEs MAY be retransmitted without incrementing SEQ. If the same UPDATEs MAY be retransmitted without incrementing SEQ. If the same
subset of parameters is included in multiple UPDATEs with different subset of parameters is included in multiple UPDATEs with different
SEQs, the host MUST ensure that the receiver's processing of the SEQs, the host MUST ensure that the receiver's processing of the
parameters multiple times will not result in a protocol error. parameters multiple times will not result in a protocol error.
5.3.6. NOTIFY - the HIP Notify Packet 5.3.6. NOTIFY - the HIP Notify Packet
Implementing the NOTIFY packet is optional. The NOTIFY packet MAY be The NOTIFY packet MAY be used to provide information to a peer.
used to provide information to a peer. Typically, NOTIFY is used to Typically, NOTIFY is used to indicate some type of protocol error or
indicate some type of protocol error or negotiation failure. NOTIFY negotiation failure. NOTIFY packets are unacknowledged. The
packets are unacknowledged. The receiver can handle the packet only receiver can handle the packet only as informational, and SHOULD NOT
as informational, and SHOULD NOT change its HIP state (see change its HIP state (see Section 4.4.2) based purely on a received
Section 4.4.2) based purely on a received NOTIFY packet. NOTIFY packet.
The HIP header values for the NOTIFY packet: The HIP header values for the NOTIFY packet:
Header: Header:
Packet Type = 17 Packet Type = 17
SRC HIT = Sender's HIT SRC HIT = Sender's HIT
DST HIT = Recipient's HIT, or zero if unknown DST HIT = Recipient's HIT, or zero if unknown
IP ( HIP (<NOTIFICATION>i, [HOST_ID, ] HIP_SIGNATURE) ) IP ( HIP (<NOTIFICATION>i, [HOST_ID, ] HIP_SIGNATURE) )
skipping to change at page 79, line 51 skipping to change at page 79, line 29
If it is not, the implementation MAY replace the source address If it is not, the implementation MAY replace the source address
with a HIT. Otherwise, it MUST drop the packet. with a HIT. Otherwise, it MUST drop the packet.
2. If the datagram has an unspecified source address, the 2. If the datagram has an unspecified source address, the
implementation MUST choose a suitable source HIT for the implementation MUST choose a suitable source HIT for the
datagram. Selecting the source HIT is subject to local policy. datagram. Selecting the source HIT is subject to local policy.
3. If there is no active HIP association with the given <source, 3. If there is no active HIP association with the given <source,
destination> HIT pair, one MUST be created by running the base destination> HIT pair, one MUST be created by running the base
exchange. While waiting for the base exchange to complete, the exchange. While waiting for the base exchange to complete, the
implementation SHOULD queue at least one packet per HIP implementation SHOULD queue at least one user data packet per HIP
association to be formed, and it MAY queue more than one. association to be formed, and it MAY queue more than one.
4. Once there is an active HIP association for the given <source, 4. Once there is an active HIP association for the given <source,
destination> HIT pair, the outgoing datagram is passed to destination> HIT pair, the outgoing datagram is passed to
transport handling. The possible transport formats are defined transport handling. The possible transport formats are defined
in separate documents, of which the ESP transport format for HIP in separate documents, of which the ESP transport format for HIP
is mandatory for all HIP implementations. is mandatory for all HIP implementations.
5. Before sending the packet, the HITs in the datagram are replaced 5. Before sending the packet, the HITs in the datagram are replaced
with suitable IP addresses. For IPv6, the rules defined in with suitable IP addresses. For IPv6, the rules defined in
skipping to change at page 82, line 35 skipping to change at page 82, line 13
Rejects if V != 0 Rejects if V != 0
Accept if V == 0 Accept if V == 0
6.4. HIP_MAC and SIGNATURE Calculation and Verification 6.4. HIP_MAC and SIGNATURE Calculation and Verification
The following subsections define the actions for processing HIP_MAC, The following subsections define the actions for processing HIP_MAC,
HIP_MAC_2, HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. The HIP_MAC_2, HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. The
HIP_MAC_2 parameter is contained in the R2 packet. The HIP_MAC_2 parameter is contained in the R2 packet. The
HIP_SIGNATURE_2 parameter is contained in the R1 packet. The HIP_SIGNATURE_2 parameter is contained in the R1 packet. The
HIP_SIGNATURE and HIP_MAC parameter are contained in other HIP HIP_SIGNATURE and HIP_MAC parameter are contained in other HIP
control packets. packets.
6.4.1. HMAC Calculation 6.4.1. HMAC Calculation
The HMAC uses RHASH as underlying hash function. The type of RHASH The HMAC uses RHASH as underlying hash function. The type of RHASH
depends on the HIT Suite of the Responder. Hence, HMAC-SHA-256 depends on the HIT Suite of the Responder. Hence, HMAC-SHA-256
[RFC4868] is used for HIT Suite RSA/DSA/SHA-256, HMAC-SHA-1 [RFC2404] [RFC4868] is used for HIT Suite RSA/DSA/SHA-256, HMAC-SHA-1 [RFC2404]
is used for HIT Suite ECDSA_LOW/SHA-1, and HMAC-SHA-384 [RFC4868] for is used for HIT Suite ECDSA_LOW/SHA-1, and HMAC-SHA-384 [RFC4868] for
HIT Suite ECDSA/SHA-384. HIT Suite ECDSA/SHA-384.
The following process applies both to the HIP_MAC and HIP_MAC_2 The following process applies both to the HIP_MAC and HIP_MAC_2
skipping to change at page 89, line 17 skipping to change at page 88, line 47
addresses. The selection of which address to use is a local addresses. The selection of which address to use is a local
policy decision. policy decision.
3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The 3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The
selection and order of DH Group IDs in the DH_GROUP_LIST MUST be selection and order of DH Group IDs in the DH_GROUP_LIST MUST be
stored by the Initiator because this list is needed for later R1 stored by the Initiator because this list is needed for later R1
processing. In most cases, the preferences regarding the DH processing. In most cases, the preferences regarding the DH
Groups will be static, so no per-association storage is Groups will be static, so no per-association storage is
necessary. necessary.
4. Upon sending an I1 packet, the sender transitions to state I1- 4. Upon sending an I1 packet, the sender transitions to state
SENT, starts a timer for which the timeout value SHOULD be larger I1-SENT, starts a timer for which the timeout value SHOULD be
than the worst-case anticipated RTT. The sender SHOULD also larger than the worst-case anticipated RTT. The sender SHOULD
increment the timeout counter associated with the I1. also increment the trial counter associated with the I1.
5. Upon timeout, the sender SHOULD retransmit the I1 packet and 5. Upon timeout, the sender SHOULD retransmit the I1 packet and
restart the timer, up to a maximum of I1_RETRIES_MAX tries. restart the timer, up to a maximum of I1_RETRIES_MAX tries.
6.6.1. Sending Multiple I1 Packets in Parallel 6.6.1. Sending Multiple I1 Packets in Parallel
For the sake of minimizing the session establishment latency, an For the sake of minimizing the association establishment latency, an
implementation MAY send the same I1 packet to more than one of the implementation MAY send the same I1 packet to more than one of the
Responder's addresses. However, it MUST NOT send to more than three Responder's addresses. However, it MUST NOT send to more than three
(3) Responder addresses in parallel. Furthermore, upon timeout, the (3) Responder addresses in parallel. Furthermore, upon timeout, the
implementation MUST refrain from sending the same I1 packet to implementation MUST refrain from sending the same I1 packet to
multiple addresses. That is, if it retries to initialize the multiple addresses. That is, if it retries to initialize the
connection after a timeout, it MUST NOT send the I1 packet to more connection after a timeout, it MUST NOT send the I1 packet to more
than one destination address. These limitations are placed in order than one destination address. These limitations are placed in order
to avoid congestion of the network, and potential DoS attacks that to avoid congestion of the network, and potential DoS attacks that
might occur, e.g., because someone's claim to have hundreds or might occur, e.g., because someone's claim to have hundreds or
thousands of addresses could generate a huge number of I1 packets thousands of addresses could generate a huge number of I1 packets
skipping to change at page 94, line 49 skipping to change at page 94, line 31
format parameter in the subsequent I2 packet. format parameter in the subsequent I2 packet.
16. The system initializes the remaining variables in the associated 16. The system initializes the remaining variables in the associated
state, including Update ID counters. state, including Update ID counters.
17. 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.
18. 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 trial counter associated with the I2 packet. The sender SHOULD
SHOULD retransmit the I2 packet upon a timeout and restart the retransmit the I2 packet upon a timeout and restart the timer,
timer, up to a maximum of I2_RETRIES_MAX tries. up to a maximum of I2_RETRIES_MAX tries.
19. 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
skipping to change at page 96, line 27 skipping to change at page 96, line 12
The local Diffie-Hellman key and the nonce I are the ones that The local Diffie-Hellman key and the nonce I are the ones that
were sent earlier in the R1 packet. were sent earlier in the R1 packet.
6. If the system's state machine is in the I1-SENT state, and the 6. If the system's state machine is in the I1-SENT state, and the
HITs in the I2 packet match those used in the previously sent I1 HITs in the I2 packet match those used in the previously sent I1
packet, the system uses this received I2 packet as the basis for packet, the system uses this received I2 packet as the basis for
the HIP association it was trying to form, and stops the HIP association it was trying to form, and stops
retransmitting I1 packets (provided that the I2 packet passes retransmitting I1 packets (provided that the I2 packet passes
the additional checks below). the additional checks below).
7. If the system's state machine is in any other state than R2- 7. If the system's state machine is in any other state than
SENT, the system SHOULD check that the echoed R1 generation R2-SENT, the system SHOULD check that the echoed R1 generation
counter in the I2 packet is within the acceptable range if the counter in the I2 packet is within the acceptable range if the
counter is included. Implementations MUST accept puzzles from counter is included. Implementations MUST accept puzzles from
the current generation and MAY accept puzzles from earlier the current generation and MAY accept puzzles from earlier
generations. If the generation counter in the newly received I2 generations. If the generation counter in the newly received I2
packet is outside the accepted range, the I2 packet is stale packet is outside the accepted range, the I2 packet is stale
(and perhaps replayed) and SHOULD be dropped. (and perhaps replayed) and SHOULD be dropped.
8. The system MUST validate the solution to the puzzle by computing 8. The system MUST validate the solution to the puzzle by computing
the hash described in Section 5.3.3 using the same RHASH the hash described in Section 5.3.3 using the same RHASH
algorithm. algorithm.
skipping to change at page 97, line 36 skipping to change at page 97, line 22
17. The I2 packet may have the A bit set -- in this case, the system 17. 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.
18. The system initializes the remaining variables in the associated 18. The system initializes the remaining variables in the associated
state, including Update ID counters. state, including Update ID counters.
19. Upon successful processing of an I2 message when the system's 19. Upon successful processing of an I2 message when the system's
state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2- state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or
SENT, an R2 packet is sent and the system's state machine R2-SENT, an R2 packet is sent and the system's state machine
transitions to state R2-SENT. transitions to state R2-SENT.
20. Upon successful processing of an I2 packet when the system's 20. Upon successful processing of an I2 packet when the system's
state machine is in state ESTABLISHED, the old HIP association state machine is in state ESTABLISHED, the old HIP association
is dropped and a new one is installed, an R2 packet is sent, and is dropped and a new one is installed, an R2 packet is sent, and
the system's state machine transitions to R2-SENT. the system's state machine transitions to R2-SENT.
21. Upon the system's state machine transitioning to R2-SENT, the 21. Upon the system's state machine transitioning to R2-SENT, the
system starts a timer. The state machine transitions to system starts a timer. The state machine transitions to
ESTABLISHED if some data has been received on the incoming HIP ESTABLISHED if some data has been received on the incoming HIP
skipping to change at page 103, line 24 skipping to change at page 103, line 21
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 HIs are used repeatedly with the basic privacy. Whether such private HIs are used repeatedly with the
same Responder and how long these HIs are used is decided by local same Responder and how long these HIs are used is decided by local
policy and depends on the privacy requirements of the Initiator. policy and depends on the privacy requirements of the 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
preferred transform and local lifetimes. Wildcarding SHOULD be preferred transport format and local lifetimes. Wildcarding SHOULD
supported for such ACLs, and also for Responders that offer public or be supported for such ACLs, and also for Responders that offer public
anonymous services. or anonymous services.
8. Security Considerations 8. Security Considerations
HIP is designed to provide secure authentication of hosts. HIP also HIP is designed to provide secure authentication of hosts. HIP also
attempts to limit the exposure of the host to various denial-of- attempts to limit the exposure of the host to various denial-of-
service and man-in-the-middle (MitM) attacks. In doing so, HIP service and man-in-the-middle (MitM) attacks. In doing so, HIP
itself is subject to its own DoS and MitM attacks that potentially itself is subject to its own DoS and MitM attacks that potentially
could be more damaging to a host's ability to conduct business as could be more damaging to a host's ability to conduct business as
usual. usual.
skipping to change at page 106, line 29 skipping to change at page 106, line 25
message. Hence, the Responder SHOULD NOT act on such an ICMP message. Hence, the Responder SHOULD NOT act on such an ICMP
message. Especially, it SHOULD NOT remove any minimal state created message. Especially, it SHOULD NOT remove any minimal state created
when it sent the R1 HIP packet (if it did create one), but wait for when it sent the R1 HIP packet (if it did create one), but wait for
either a valid I2 HIP packet or the natural timeout (that is, if R1 either a valid I2 HIP packet or the natural timeout (that is, if R1
packets are tracked at all). Likewise, the Initiator SHOULD ignore packets are tracked at all). Likewise, the Initiator SHOULD ignore
any ICMP message while waiting for an R2 HIP packet, and SHOULD any ICMP message while waiting for an R2 HIP packet, and SHOULD
delete any pending state only after a natural timeout. delete any pending state only after a natural timeout.
9. IANA Considerations 9. IANA Considerations
IANA has reserved protocol number 139 for the Host Identity Protocol. IANA has reserved protocol number 139 for the Host Identity Protocol
and included it in the "IPv6 Extension Header Types" registry
[RFC7045]. No new action regarding this value is required by this
specification.
This document defines a new 128-bit value under the CGA Message Type The reference to the 128-bit value under the CGA Message Type
namespace [RFC3972], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, to be namespace [RFC3972] of "0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA"
used for HIT generation as specified in ORCHID should be changed from [RFC5201] to this specification.
[I-D.ietf-hip-rfc4843-bis].
This document uses HIP version number 2 for the four-bit Version The following changes to the "Host Identity Protocol (HIP)
field in a HIP protocol packet defined in [RFC5201]. Parameters" registries are requested. In many cases, the changes
required involve updating the reference from [RFC5201] to this
specification, but there are some differences as outlined below.
Allocation terminology is defined in [RFC5226]; any existing
references to "IETF Consensus" can be replaced with "IETF Review" as
per [RFC5226].
This document also creates a set of new namespaces. These are HIP Version
described below.
This document adds the value "2" to the existing registry. The
value of "1" should be left with a reference to [RFC5201].
Packet Type Packet Type
The 7-bit Packet Type field in a HIP protocol packet describes the The 7-bit Packet Type field in a HIP protocol packet describes the
type of a HIP protocol message. It is defined in Section 5.1. type of a HIP protocol message. It is defined in Section 5.1.
The current values are defined in Sections 5.3.1 through 5.3.8. All existing values referring to [RFC5201] should be updated to
refer to this specification. Other values should be left
unchanged.
New values are assigned through IETF Review or IESG Approval HIT Suite ID
[RFC5226].
HIT Suite This specification creates a new registry for "HIT Suite ID".
This is different than the existing registry for "Suite ID" which
can be left unmodified for version 1 of the protocol ([RFC5201]).
The four-bit HIT Suite ID uses the OGA field in the ORCHID to The four-bit HIT Suite ID uses the OGA field in the ORCHID to
express the type of the HIT. This document defines two HIT Suites express the type of the HIT. This document defines three HIT
(see Appendix E). Suites (see Appendix E).
The HIT Suite ID is also carried in the four higher-order bits of The HIT Suite ID is also carried in the four higher-order bits of
the ID field in the HIT_SUITE_LIST parameter. The four lower- the ID field in the HIT_SUITE_LIST parameter. The four lower-
order bits are reserved for future extensions of the HIT Suite ID order bits are reserved for future extensions of the HIT Suite ID
space beyond 16 values. space beyond 16 values.
At the time being, the HIT Suite uses only four bits because these For the time being, the HIT Suite uses only four bits because
bits have to be carried in the HIT. Using more bits for the HIT these bits have to be carried in the HIT. Using more bits for the
Suite ID reduces the cryptographic strength of the HIT. HIT Suite HIT Suite ID reduces the cryptographic strength of the HIT. HIT
IDs must be allocated carefully to avoid namespace exhaustion. Suite IDs must be allocated carefully to avoid namespace
Moreover, deprecated IDs should be reused after an appropriate exhaustion. Moreover, deprecated IDs should be reused after an
time span. If 16 Suite IDs prove insufficient and more HIT Suite appropriate time span. If 16 Suite IDs prove insufficient and
IDs are needed concurrently, more bits can be used for the HIT more HIT Suite IDs are needed concurrently, more bits can be used
Suite ID by using one HIT Suite ID (0) to indicate that more bits for the HIT Suite ID by using one HIT Suite ID (0) to indicate
should be used. The HIT_SUITE_LIST parameter already supports that more bits should be used. The HIT_SUITE_LIST parameter
8-bit HIT Suite IDs, should longer IDs be needed. Possible already supports 8-bit HIT Suite IDs, should longer IDs be needed.
extensions of the HIT Suite ID space to accommodate eight bits and Possible extensions of the HIT Suite ID space to accommodate eight
new HIT Suite IDs are defined through IETF Review or IESG bits and new HIT Suite IDs are defined through IETF Review.
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.23. are defined in Sections 5.2.3 through 5.2.23. The existing
registry for "Parameter Type" should be updated as follows.
With the exception of the assigned Type codes, the Type codes 0 A new value (129) for R1_COUNTER should be introduced, with a
through 1023 and 61440 through 65535 are reserved for future base reference to this specification, and the existing value (128) for
protocol extensions, and are assigned through IETF Review or IESG R1_COUNTER left in place with a reference to [RFC5201]. This
Approval. documents the change in value that has occurred in version 2 of
this protocol.
A new value (579) for a new Parameter Type HIP_CIPHER should be
added, with reference to this specification. This Parameter Type
functionally replaces the HIP_TRANSFORM Parameter Type (value 577)
which can be left in the table with existing reference to
[RFC5201].
A new value (715) for a new Parameter Type HIT_SUITE_LIST should
be added, with reference to this specification.
A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST
should be added, with reference to this specification.
The name of the HMAC Parameter Type (value 61505) should be
changed to HIP_MAC. The name of the HMAC_2 Parameter Type (value
61569) should be changed to HIP_MAC_2.
All other Parameter Types that reference [RFC5201] should be
updated to refer to this specification, and Parameter Types that
reference other RFCs should be unchanged.
Regarding the range assignments, the Type codes 32768 through
49151 (not 49141) should be Reserved for Private Use. Where the
existing ranges state "First Come First Served with Specification
Required", this should be changed to "Specification Required".
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,
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.7. New values are assigned through IETF Review or Section 5.2.7. This registry should be updated based on the new
IESG Approval. values specified in Section 5.2.7; values noted as being
DEPRECATED can be left in the table with reference to [RFC5201].
New values are assigned through IETF Review.
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.8. New values either from the reserved or in Section 5.2.8. This is a new registry. New values either from
unassigned space are assigned through IETF Review or IESG the reserved or unassigned space are assigned through IETF Review.
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.9. New values are assigned through IETF Review or Section 5.2.9. New values are assigned through IETF Review. All
IESG Approval. existing values referring to [RFC5201] should be updated to refer
to this specification.
HI Algorithm
The 16-bit Algorithm values in a HOST_ID parameter are defined in
Section 5.2.9. This is a new registry. New values either from
the reserved or unassigned space are assigned through IETF Review.
ECC Curve Label
When the HI Algorithm values in a HOST_ID parameter is defined to
the values of either "ECDSA" or "ECDSA_LOW", a new registry is
needed to maintain the values for the ECC Curve Label as defined
in Section 5.2.9. This might be handled by specifying two
algorithm-specific sub-registries named "ECDSA Curve Label" and
"ECDSA_LOW Curve Label". New values are to be assigned through
IETF Review.
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.19. 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.
51-8191 are error types reserved to be allocated by IANA. Values
8192-16383 are error types for experimentation. Values 16385- The existing registration procedures should be updated as follows.
40959 are status types to be allocated by IANA, and values 40960- The range from 1-50 can remain as "IETF Review". The range from
65535 are status types for experimentation. New values in ranges 51-8191 should be marked as "Specification Required". Values
51-8191 and 16385-40959 are assigned through First Come First 8192-16383 can remain as "Reserved for Private Use". Values
Served, with Specification Required. 16385-40959 should be marked as "Specification Required". Values
40960-65535 can remain as "Reserved for Private Use".
The following updates to the values should be made to the existing
registry. All existing values referring to [RFC5201] should be
updated to refer to this specification.
INVALID_HIP_TRANSFORM_CHOSEN should be renamed to
INVALID_HIP_CIPHER_CHOSEN with the same value (17).
A new value of 20 for the type UNSUPPORTED_HIT_SUITE should be
added.
HMAC_FAILED should be renamed to HIP_MAC_FAILED with the same
value (28).
SERVER_BUSY_PLEASE_RETRY should be renamed to
RESPONDER_BUSY_PLEASE_RETRY with the same value (44).
10. Acknowledgments 10. Acknowledgments
The drive to create HIP came to being after attending the MALLOC The drive to create HIP came to being after attending the MALLOC
meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman
really gave the original author, Bob Moskowitz, the assist to get HIP really gave the original author, Bob Moskowitz, the assist to get HIP
beyond 5 paragraphs of ideas. It has matured considerably since the beyond 5 paragraphs of ideas. It has matured considerably since the
early versions thanks to extensive input from IETFers. Most early versions thanks to extensive input from IETFers. Most
importantly, its design goals are articulated and are different from importantly, its design goals are articulated and are different from
other efforts in this direction. Particular mention goes to the other efforts in this direction. Particular mention goes to the
skipping to change at page 109, line 44 skipping to change at page 111, line 12
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-12 11.1. Changes from draft-ietf-hip-rfc5201-bis-14
o Update source XML to comply with xmlrfcv2 version of the xml2rfc
tool, resulting in a few table formatting changes.
o Editorial and minor technical revisions based on IESG review.
o Significant revisions to IANA Considerations section based on
initial IANA review.
11.2. Changes from draft-ietf-hip-rfc5201-bis-13
o Update a few references and fix some editorial nits.
11.3. Changes from draft-ietf-hip-rfc5201-bis-12
o Fix I-D nits. o Fix I-D nits.
11.2. Changes from draft-ietf-hip-rfc5201-bis-11 11.4. Changes from draft-ietf-hip-rfc5201-bis-11
o Specify that TRANSFORM_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.3. Changes from draft-ietf-hip-rfc5201-bis-10 11.5. 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.4. Changes from draft-ietf-hip-rfc5201-bis-09 11.6. 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.5. Changes from draft-ietf-hip-rfc5201-bis-08 11.7. 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.6. Changes from draft-ietf-hip-rfc5201-bis-07 11.8. 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.7. Changes from draft-ietf-hip-rfc5201-bis-06 11.9. 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.8. Changes from draft-ietf-hip-rfc5201-bis-05 11.10. 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 111, line 39 skipping to change at page 113, line 12
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.9. Changes from draft-ietf-hip-rfc5201-bis-04 11.11. 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 112, line 40 skipping to change at page 114, line 13
achieve alignment with the HOST_ID parameters. achieve alignment with the HOST_ID parameters.
o Fixed the wrong figures of the SEQ and ACK parameters. SEQ always o Fixed the wrong figures of the SEQ and ACK parameters. SEQ always
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 packet. This did contradict
contradict the definition of the ECHO_RESPONSE_UNSIGNED parameter. the definition of the ECHO_RESPONSE_UNSIGNED parameter.
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.10. Changes from draft-ietf-hip-rfc5201-bis-03 11.12. 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 113, line 41 skipping to change at page 115, line 13
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.11. Changes from draft-ietf-hip-rfc5201-bis-02 11.13. 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.12. Changes from draft-ietf-hip-rfc5201-bis-01 11.14. 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 116, line 5 skipping to change at page 117, line 24
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.13. Changes from draft-ietf-hip-rfc5201-bis-00 11.15. 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.14. Contents of draft-ietf-hip-rfc5201-bis-00 11.16. 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]
Technology, "Secure Hash Standard", National Institute of Standards and Technology, "Secure
FIPS PUB 180-2, August 2002, <http:// Hash Standard", FIPS PUB 180-2, August 2002,
csrc.nist.gov/publications/fips/ <http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2/fips180-2.pdf>. fips180-2.pdf>.
[I-D.ietf-hip-rfc4843-bis] Laganier, J. and F. Dupont, "An IPv6 [I-D.ietf-hip-rfc4843-bis]
Prefix for Overlay Routable Cryptographic Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
Hash Identifiers Version 2 (ORCHIDv2)", Routable Cryptographic Hash Identifiers Version 2
draft-ietf-hip-rfc4843-bis-04 (work in (ORCHIDv2)", draft-ietf-hip-rfc4843-bis-04 (work in
progress), May 2013. progress), May 2013.
[I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., and J. Melen, [I-D.ietf-hip-rfc5202-bis]
"Using the Encapsulating Security Payload Jokela, P., Moskowitz, R., and J. Melen, "Using the
(ESP) Transport Format with the Host Encapsulating Security Payload (ESP) Transport Format with
Identity Protocol (HIP)", the Host Identity Protocol (HIP)", draft-ietf-hip-
draft-ietf-hip-rfc5202-bis-04 (work in rfc5202-bis-05 (work in progress), November 2013.
progress), September 2013.
[NIST.800-131A.2011] National Institute of Standards and [NIST.800-131A.2011]
Technology, "Transitions: Recommendation National Institute of Standards and Technology,
for Transitioning the Use of "Transitions: Recommendation for Transitioning the Use of
Cryptographic Algorithms and Key Cryptographic Algorithms and Key Lengths", NIST 800-131A,
Lengths", NIST 800-131A, January 2011. January 2011.
[RFC0768] Postel, J., "User Datagram Protocol", [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
STD 6, RFC 768, August 1980. August 1980.
[RFC1035] Mockapetris, P., "Domain names - [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
implementation and specification", 793, September 1981.
STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs [RFC1035] Mockapetris, P., "Domain names - implementation and
to Indicate Requirement Levels", BCP 14, specification", STD 13, RFC 1035, November 1987.
RFC 2119, March 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
HMAC-SHA-1-96 within ESP and AH", Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2404, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
Encryption Algorithm and Its Use With ESP and AH", RFC 2404, November 1998.
IPsec", RFC 2410, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Protocol, Version 6 (IPv6) Its Use With IPsec", RFC 2410, November 1998.
Specification", RFC 2460, December 1998.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
Domain Name System (DNS)", RFC 2536, (IPv6) Specification", RFC 2460, December 1998.
March 1999.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
KEYs in the Domain Name System (DNS)", (DNS)", RFC 2536, March 1999.
RFC 3110, May 2001.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Exponential (MODP) Diffie-Hellman groups Name System (DNS)", RFC 3110, May 2001.
for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
"The AES-CBC Cipher Algorithm and Its Use Diffie-Hellman groups for Internet Key Exchange (IKE)",
with IPsec", RFC 3602, September 2003. RFC 3526, May 2003.
[RFC3972] Aura, T., "Cryptographically Generated [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Addresses (CGA)", RFC 3972, March 2005. Algorithm and Its Use with IPsec", RFC 3602, September
2003.
[RFC4034] Arends, R., Austein, R., Larson, M., [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
Massey, D., and S. Rose, "Resource RFC 3972, March 2005.
Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Eronen, "The Network Access Identifier", Rose, "Resource Records for the DNS Security Extensions",
RFC 4282, December 2005. RFC 4034, March 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
"Internet Control Message Protocol Network Access Identifier", RFC 4282, December 2005.
(ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification",
RFC 4443, March 2006.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Authentication Using the Elliptic Curve Message Protocol (ICMPv6) for the Internet Protocol
Digital Signature Algorithm (ECDSA)", Version 6 (IPv6) Specification", RFC 4443, March 2006.
RFC 4754, January 2007.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC- [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
SHA-256, HMAC-SHA-384, and HMAC-SHA-512 the Elliptic Curve Digital Signature Algorithm (ECDSA)",
with IPsec", RFC 4868, May 2007. RFC 4754, January 2007.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
RSA in DNSKEY and RRSIG Resource Records 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
for DNSSEC", RFC 5702, October 2009.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
and T. Chown, "Default Address Selection and RRSIG Resource Records for DNSSEC", RFC 5702, October
for Internet Protocol Version 6 (IPv6)", 2009.
RFC 6724, September 2012.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
12.2. Informative References 12.2. Informative References
[AUR03] Aura, T., Nagarajan, A., and A. Gurtov, [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the
"Analysis of the HIP Base Exchange HIP Base Exchange Protocol", in Proceedings of 10th
Protocol", in Proceedings of 10th Australasian Conference on Information Security and
Australasian Conference on Information Privacy, July 2003.
Security and Privacy, July 2003.
[CRO03] Crosby, SA. and DS. Wallach, "Denial of [CRO03] Crosby, SA. and DS. Wallach, "Denial of Service via
Service via Algorithmic Complexity Algorithmic Complexity Attacks", in Proceedings of Usenix
Attacks", in Proceedings of Usenix Security Symposium 2003, Washington, DC., August 2003.
Security Symposium 2003, Washington,
DC., August 2003.
[DIF76] Diffie, W. and M. Hellman, "New [DIF76] Diffie, W. and M. Hellman, "New Directions in
Directions in Cryptography", IEEE Cryptography", IEEE Transactions on Information Theory
Transactions on Information Theory vol. vol. IT-22, number 6, pages 644-654, Nov 1976.
IT-22, number 6, pages 644-654, Nov 1976.
[FIPS.197.2001] National Institute of Standards and [FIPS.197.2001]
Technology, "Advanced Encryption Standard National Institute of Standards and Technology, "Advanced
(AES)", FIPS PUB 197, November 2001, <htt Encryption Standard (AES)", FIPS PUB 197, November 2001,
p://csrc.nist.gov/publications/fips/ <http://csrc.nist.gov/publications/fips/fips197/
fips197/fips-197.pdf>. fips-197.pdf>.
[FIPS186-3] U.S. Department of Commerce/National [FIPS186-3]
Institute of Standards and Technology, U.S. Department of Commerce/National Institute of
"FIPS PUB 186-3: Digital Signature Standards and Technology, "FIPS PUB 186-3: Digital
Standard (DSS).", June 2009. Signature Standard (DSS).", June 2009.
[I-D.ietf-btns-c-api] Richardson, M., Williams, N., Komu, M., [I-D.ietf-hip-rfc4423-bis]
and S. Tarkoma, "C-Bindings for IPsec Moskowitz, R., "Host Identity Protocol Architecture",
Application Programming Interfaces", draft-ietf-hip-rfc4423-bis-05 (work in progress),
draft-ietf-btns-c-api-04 (work in September 2012.
progress), March 2009.
[I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol [I-D.ietf-hip-rfc5204-bis]
Architecture", Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
draft-ietf-hip-rfc4423-bis-05 (work in Rendezvous Extension", draft-ietf-hip-rfc5204-bis-02 (work
progress), September 2012. in progress), September 2012.
[I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host [I-D.ietf-hip-rfc5205-bis]
Identity Protocol (HIP) Rendezvous Laganier, J., "Host Identity Protocol (HIP) Domain Name
Extension", draft-ietf-hip-rfc5204-bis-02 System (DNS) Extension", draft-ietf-hip-rfc5205-bis-02
(work in progress), September 2012. (work in progress), September 2012.
[I-D.ietf-hip-rfc5205-bis] Laganier, J., "Host Identity Protocol [I-D.ietf-hip-rfc5206-bis]
(HIP) Domain Name System (DNS) Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with
Extension", draft-ietf-hip-rfc5205-bis-02 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-06
(work in progress), September 2012. (work in progress), July 2013.
[I-D.ietf-hip-rfc5206-bis] Henderson, T., Vogt, C., and J. Arkko, [KAU03] Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS
"Host Mobility with the Host Identity protection for UDP-based protocols", ACM Conference on
Protocol", draft-ietf-hip-rfc5206-bis-06 Computer and Communications Security , Oct 2003.
(work in progress), July 2013.
[KAU03] Kaufman, C., Perlman, R., and B. [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to
Sommerfeld, "DoS protection for UDP-based Authenticated Diffie-Hellman and Its Use in the IKE-
protocols", ACM Conference on Computer Protocols", in Proceedings of CRYPTO 2003, pages 400-425,
and Communications Security , Oct 2003. August 2003.
[KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
Approach to Authenticated Diffie-Hellman RFC 792, September 1981.
and Its Use in the IKE-Protocols", in
Proceedings of CRYPTO 2003, pages 400-
425, August 2003.
[RFC0792] Postel, J., "Internet Control Message [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
Protocol", STD 5, RFC 792, Attacks on the Diffie-Hellman Key Agreement Method for S/
September 1981. MIME", RFC 2785, March 2000.
[RFC2785] Zuccherato, R., "Methods for Avoiding the [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
"Small-Subgroup" Attacks on the Diffie- Specification Version 2.0", RFC 2898, September 2000.
Hellman Key Agreement Method for S/MIME",
RFC 2785, March 2000.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Cryptography Specification Version 2.0", Standards (PKCS) #1: RSA Cryptography Specifications
RFC 2898, September 2000. Version 2.1", RFC 3447, February 2003.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Cryptography Standards (PKCS) #1: RSA Reserved for Documentation", RFC 3849, July 2004.
Cryptography Specifications Version 2.1",
RFC 3447, February 2003.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
Address Prefix Reserved for "Host Identity Protocol", RFC 5201, April 2008.
Documentation", RFC 3849, July 2004.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
and T. Henderson, "Host Identity IANA Considerations Section in RFCs", BCP 26, RFC 5226,
Protocol", RFC 5201, April 2008. May 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host
for Writing an IANA Considerations Identity Protocol with Legacy Applications", RFC 5338,
Section in RFCs", BCP 26, RFC 5226, September 2008.
May 2008.
[RFC5338] Henderson, T., Nikander, P., and M. Komu, [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
"Using the Host Identity Protocol with Shim Protocol for IPv6", RFC 5533, June 2009.
Legacy Applications", RFC 5338,
September 2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: [RFC5747] Wu, J., Cui, Y., Li, X., Xu, M., and C. Metz, "4over6
Level 3 Multihoming Shim Protocol for Transit Solution Using IP Encapsulation and MP-BGP
IPv6", RFC 5533, June 2009. Extensions", RFC 5747, March 2010.
[RFC5747] Wu, J., Cui, Y., Li, X., Xu, M., and C. [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Metz, "4over6 Transit Solution Using IP Key Derivation Function (HKDF)", RFC 5869, May 2010.
Encapsulation and MP-BGP Extensions",
RFC 5747, March 2010.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
Extract-and-Expand Key Derivation Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June
Function (HKDF)", RFC 5869, May 2010. 2010.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
Groups modulo a Prime (ECP Groups) for "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
IKE and IKEv2", RFC 5903, June 2010. 5996, September 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Eronen, "Internet Key Exchange Protocol Curve Cryptography Algorithms", RFC 6090, February 2011.
Version 2 (IKEv2)", RFC 5996,
September 2010.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol
"Fundamental Elliptic Curve Cryptography Certificates", RFC 6253, May 2011.
Algorithms", RFC 6090, February 2011.
[RFC6253] Heer, T. and S. Varjonen, "Host Identity [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
Protocol Certificates", RFC 6253, of IPv6 Extension Headers", RFC 7045, December 2013.
May 2011.
[SECG] SECG, "Recommended Elliptic Curve Domain [SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC
Parameters", SEC 2 , 2000, 2 , 2000, <http://www.secg.org/>.
<http://www.secg.org/>.
Appendix A. Using Responder Puzzles Appendix A. Using Responder Puzzles
As mentioned in Section 4.1.1, the Responder may delay state creation As mentioned in Section 4.1.1, the Responder may delay state creation
and still reject most spoofed I2 packets by using a number of pre- and still reject most spoofed I2 packets by using a number of pre-
calculated R1 packets and a local selection function. This appendix calculated R1 packets and a local selection function. This appendix
defines one possible implementation in detail. The purpose of this defines one possible implementation in detail. The purpose of this
appendix is to give the implementors an idea on how to implement the appendix is to give the implementors an idea on how to implement the
mechanism. If the implementation is based on this appendix, it MAY mechanism. If the implementation is based on this appendix, it MAY
contain some local modification that makes an attacker's task harder. contain some local modification that makes an attacker's task harder.
skipping to change at page 121, line 50 skipping to change at page 122, line 42
where n = RHASH_len where n = RHASH_len
The RHASH algorithm is the same that is used to generate the The RHASH algorithm is the same that is used to generate the
Responder's HIT value. Responder's HIT value.
From an incoming I2 packet, the Responder receives the required From an incoming I2 packet, the Responder receives the required
information to validate the puzzle: HITs, IP addresses, and the information to validate the puzzle: HITs, IP addresses, and the
information of the used S value from the R1_COUNTER. Using these information of the used S value from the R1_COUNTER. Using these
values, the Responder can regenerate the #I, and verify it against values, the Responder can regenerate the #I, and verify it against
the #I received in the I2 packet. If the #I values match, it can the #I received in the I2 packet. If the #I values match, it can
verify the solution using #I, #J, and difficulty #K. If the #I values verify the solution using #I, #J, and difficulty #K. If the #I
do not match, the I2 is dropped. values do not match, the I2 is dropped.
puzzle_check: puzzle_check:
V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K ) V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K )
if V != 0, drop the packet if V != 0, drop the packet
If the puzzle solution is correct, the #I and #J values are stored If the puzzle solution is correct, the #I and #J values are stored
for later use. They are used as input material when keying material for later use. They are used as input material when keying material
is generated. is generated.
Keeping state about failed puzzle solutions depends on the Keeping state about failed puzzle solutions depends on the
implementation. Although it is possible for the Responder not to implementation. Although it is possible for the Responder not to
keep any state information, it still may do so to protect itself keep any state information, it still may do so to protect itself
against certain attacks (see Section 4.1.1). against certain attacks (see Section 4.1.1).
Appendix B. Generating a Public Key Encoding from an HI Appendix B. Generating a Public Key Encoding from an HI
The following pseudo-code illustrates the process to generate a The following pseudo-code illustrates the process to generate a
public key encoding from an HI for both RSA and DSA. public key encoding from an HI for both RSA and DSA.
The symbol := denotes assignment; the symbol += denotes appending. The symbol ":=" denotes assignment; the symbol "+=" denotes
The pseudo-function encode_in_network_byte_order takes two appending. The pseudo-function "encode_in_network_byte_order" takes
parameters, an integer (bignum) and a length in bytes, and returns two parameters, an integer (bignum) and a length in bytes, and
the integer encoded into a byte string of the given length. returns the integer encoded into a byte string of the given length.
switch ( HI.algorithm ) switch ( HI.algorithm )
{ {
case RSA: case RSA:
buffer := encode_in_network_byte_order ( HI.RSA.e_len, buffer := encode_in_network_byte_order ( HI.RSA.e_len,
( HI.RSA.e_len > 255 ) ? 3 : 1 ) ( HI.RSA.e_len > 255 ) ? 3 : 1 )
buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len )
buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len )
break; break;
skipping to change at page 125, line 45 skipping to change at page 126, line 23
with a lower HIT Suite index than the previously introduced one. The with a lower HIT Suite index than the previously introduced one. The
rollover effectively deprecates the reused HIT Suite. For a smooth rollover effectively deprecates the reused HIT Suite. For a smooth
transition, the HIT Suite should be deprecated a considerable time transition, the HIT Suite should be deprecated a considerable time
before the HIT Suite index is reused. before the HIT Suite index is reused.
Since the number of HIT Suites is tightly limited to 16, the HIT Since the number of HIT Suites is tightly limited to 16, the HIT
Suites must be assigned carefully. Hence, sets of suitable Suites must be assigned carefully. Hence, sets of suitable
algorithms are grouped in a HIT Suite. algorithms are grouped in a HIT Suite.
The HIT Suite of the Responder's HIT determines the RHASH and the The HIT Suite of the Responder's HIT determines the RHASH and the
hash function to be used for the HMAC in HIP control packets as well hash function to be used for the HMAC in HIP packets as well as the
as the signature algorithm family used for generating the HI. The signature algorithm family used for generating the HI. The list of
list of HIT Suites is defined in Table 11. HIT Suites is defined in Table 11.
The following HIT Suites are defined for HIT generation. The input The following HIT Suites are defined for HIT generation. The input
for each generation algorithm is the encoding of the HI as defined in for each generation algorithm is the encoding of the HI as defined in
Section 3.2. The output is 96 bits long and is directly used in the Section 3.2. The output is 96 bits long and is directly used in the
ORCHID. ORCHID.
+-------+----------+--------------+------------+--------------------+ +-------+----------+--------------+------------+--------------------+
| Index | Hash | HMAC | Signature | Description | | Index | Hash | HMAC | Signature | Description |
| | function | | algorithm | | | | function | | algorithm | |
| | | | family | | | | | | family | |
skipping to change at page 127, line 4 skipping to change at page 127, line 27
EMail: robert.moskowitz@verizonbusiness.com EMail: robert.moskowitz@verizonbusiness.com
Tobias Heer Tobias Heer
Hirschmann Automation and Control Hirschmann Automation and Control
Stuttgarter Strasse 45-51 Stuttgarter Strasse 45-51
Neckartenzlingen 72654 Neckartenzlingen 72654
Germany Germany
EMail: tobias.heer@belden.com EMail: tobias.heer@belden.com
Petri Jokela Petri Jokela
Ericsson Research NomadicLab Ericsson Research NomadicLab
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
Phone: +358 9 299 1 Phone: +358 9 299 1
EMail: petri.jokela@nomadiclab.com EMail: petri.jokela@nomadiclab.com
Thomas R. Henderson Thomas R. Henderson
The Boeing Company University of Washington
P.O. Box 3707 Campus Box 352500
Seattle, WA Seattle, WA
USA USA
EMail: thomas.r.henderson@boeing.com EMail: tomhend@u.washington.edu
 End of changes. 217 change blocks. 
680 lines changed or deleted 740 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/