draft-ietf-hip-rfc5201-bis-03.txt   draft-ietf-hip-rfc5201-bis-04.txt 
Network Working Group R. Moskowitz, Ed. Network Working Group R. Moskowitz, Ed.
Internet-Draft ICSA labs Internet-Draft ICSA labs
Obsoletes: 5201 (if approved) P. Jokela Obsoletes: 5201 (if approved) P. Jokela
Intended status: Standards Track Ericsson Research NomadicLab Intended status: Standards Track Ericsson Research NomadicLab
Expires: April 26, 2011 T. Henderson Expires: July 24, 2011 T. Henderson
The Boeing Company The Boeing Company
T. Heer T. Heer
RWTH Aachen University, RWTH Aachen University,
Distributed Systems Group Communication and Distributed
October 23, 2010 Systems Group
January 20, 2011
Host Identity Protocol Host Identity Protocol
draft-ietf-hip-rfc5201-bis-03 draft-ietf-hip-rfc5201-bis-04
Abstract Abstract
This document specifies the details of the Host Identity Protocol This document specifies the details of the Host Identity Protocol
(HIP). HIP allows consenting hosts to securely establish and (HIP). HIP allows consenting hosts to securely establish and
maintain shared IP-layer state, allowing separation of the identifier maintain shared IP-layer state, allowing separation of the identifier
and locator roles of IP addresses, thereby enabling continuity of and locator roles of IP addresses, thereby enabling continuity of
communications across IP address changes. HIP is based on a SIGMA- communications across IP address changes. HIP is based on a SIGMA-
compliant Diffie-Hellman key exchange, using public key identifiers compliant Diffie-Hellman key exchange, using public key identifiers
from a new Host Identity namespace for mutual peer authentication. from a new Host Identity namespace for mutual peer authentication.
skipping to change at page 1, line 38 skipping to change at page 1, line 39
another suitable security protocol, such as the Encapsulated Security another suitable security protocol, such as the Encapsulated Security
Payload (ESP), it provides integrity protection and optional Payload (ESP), it provides integrity protection and optional
encryption for upper-layer protocols, such as TCP and UDP. encryption for upper-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 to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2011. This Internet-Draft will expire on July 24, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 2, line 49 skipping to change at page 2, line 45
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 7 1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 7
1.2. The HIP Base Exchange (BEX) . . . . . . . . . . . . . . . 7 1.2. The HIP Base Exchange (BEX) . . . . . . . . . . . . . . . 7
1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 8 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . . . 9
3. Host Identifier (HI) and Its Structure . . . . . . . . . . . 9 3. Host Identifier (HI) and its Structure . . . . . . . . . . . 9
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12 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 Negotiation . . . . . . . . . . . . . . . . . . 16 Group Negotiation . . . . . . . . . . . . . . . . . . 16
4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 17 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 18
4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 18 4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 19
4.1.6. Aborting a HIP Exchange . . . . . . . . . . . . . . . 19 4.1.6. Aborting a HIP Exchange . . . . . . . . . . . . . . . 19
4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 19 4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 20
4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 20 4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 21
4.2. Updating a HIP Association . . . . . . . . . . . . . . . 23 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 23
4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 23 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 24
4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 24 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 25
4.4.1. Timespan Definitions . . . . . . . . . . . . . . . . 25 4.4.1. Timespan Definitions . . . . . . . . . . . . . . . . 26
4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 25 4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 26
4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 26 4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 27
4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 33 4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 34
4.5. User Data Considerations . . . . . . . . . . . . . . . . 35 4.5. User Data Considerations . . . . . . . . . . . . . . . . 36
4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 35 4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 36
4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 35 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 36
4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 35 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 36
4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 35 4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 36
4.6. Certificate Distribution . . . . . . . . . . . . . . . . 36 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 37
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 36 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 37
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 36 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 37
5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 37 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 38
5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 38 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 39
5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 38 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 39
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 39 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 40
5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 42 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 43
5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 44 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 45
5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 45 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46
5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 46 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 47 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48
5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 48 5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 49
5.2.7. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 49 5.2.7. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 50
5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 50 5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.9. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 52 5.2.9. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 53
5.2.10. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 53 5.2.10. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 54
5.2.11. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 54 5.2.11. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.12. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 54 5.2.12. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 55
5.2.13. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 55 5.2.13. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 56
5.2.14. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 56 5.2.14. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 57
5.2.15. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.2.15. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.16. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.2.16. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.17. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 58 5.2.17. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 59
5.2.18. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 59 5.2.18. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 60
5.2.19. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 63 5.2.19. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 64
5.2.20. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 63 5.2.20. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 64
5.2.21. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 64 5.2.21. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 65
5.2.22. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 65 5.2.22. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 66
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 65
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 66 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 66
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 67 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 67
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 70 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 68
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 71 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 71
5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 71 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 72
5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 72 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 72
5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 73 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 73
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 73 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 74
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 74 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 74
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 74 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 75
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 75
5.4.2. Other Problems with the HIP Header and Packet 5.4.2. Other Problems with the HIP Header and Packet
Structure . . . . . . . . . . . . . . . . . . . . . . 74 Structure . . . . . . . . . . . . . . . . . . . . . . 75
5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 74 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 75
5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 75 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 76
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 75 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 76
6.1. Processing Outgoing Application Data . . . . . . . . . . 75 6.1. Processing Outgoing Application Data . . . . . . . . . . 76
6.2. Processing Incoming Application Data . . . . . . . . . . 76 6.2. Processing Incoming Application Data . . . . . . . . . . 77
6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 77 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 78
6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 79 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 80
6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 79 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 80
6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 81 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 82
6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 83 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 84
6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 84 6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 85
6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 85 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 86
6.6.2. Processing Incoming ICMP Protocol Unreachable 6.6.2. Processing Incoming ICMP Protocol Unreachable
Messages . . . . . . . . . . . . . . . . . . . . . . 86 Messages . . . . . . . . . . . . . . . . . . . . . . 87
6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 86 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 87
6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 87 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 88
6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 88 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 89
6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 88 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 89
6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 90 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 92
6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 90 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 92
6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 93 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 94
6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 93 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 95
6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 94 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 95
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 95 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 96
6.12.1. Handling a SEQ Parameter in a Received UPDATE 6.12.1. Handling a SEQ Parameter in a Received UPDATE
Message . . . . . . . . . . . . . . . . . . . . . . . 96 Message . . . . . . . . . . . . . . . . . . . . . . . 97
6.12.2. Handling an ACK Parameter in a Received UPDATE 6.12.2. Handling an ACK Parameter in a Received UPDATE
Packet . . . . . . . . . . . . . . . . . . . . . . . 96 Packet . . . . . . . . . . . . . . . . . . . . . . . 98
6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 97 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 98
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 97 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 99
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 98 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 99
6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 98 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 99
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 98 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 99
8. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 99 8. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 100
8.1. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 99 8.1. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 100
8.2. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 99 8.2. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 101
8.3. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 101 8.3. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 101
8.4. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . . 101 8.4. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 103
9. Security Considerations . . . . . . . . . . . . . . . . . . . 101 8.5. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . . 103
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 103
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 106 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 107 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 108
12.1. Normative References . . . . . . . . . . . . . . . . . . 107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 109
12.2. Informative References . . . . . . . . . . . . . . . . . 109 12.1. Normative References . . . . . . . . . . . . . . . . . . 109
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 110 12.2. Informative References . . . . . . . . . . . . . . . . . 111
Appendix B. Generating a Public Key Encoding from an HI . . . . 112 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 113
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 112 Appendix B. Generating a Public Key Encoding from an HI . . . . 115
C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 113 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 115
C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 113 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 116
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 113 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 116
Appendix D. ECDH-160 Group . . . . . . . . . . . . . . . . . . . 114 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 116
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 114 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 117
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 117
1. Introduction 1. Introduction
This memo specifies the details of the Host Identity Protocol (HIP). This document specifies the details of the Host Identity Protocol
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 [rfc4423-bis]. Briefly, the HIP architecture proposes an description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP
alternative to the dual use of IP addresses as "locators" (routing architecture proposes an alternative to the dual use of IP addresses
labels) and "identifiers" (endpoint, or host, identifiers). In HIP, as "locators" (routing labels) and "identifiers" (endpoint, or host,
public cryptographic keys, of a public/private key pair, are used as identifiers). In HIP, public cryptographic keys, of a public/private
Host Identifiers, to which higher layer protocols are bound instead key pair, are used as Host Identifiers, to which higher layer
of an IP address. By using public keys (and their representations) protocols are bound instead of an IP address. By using public keys
as host identifiers, dynamic changes to IP address sets can be (and their representations) as host identifiers, dynamic changes to
directly authenticated between hosts, and if desired, strong IP address sets can be directly authenticated between hosts, and if
authentication between hosts at the TCP/IP stack level can be desired, strong authentication between hosts at the TCP/IP stack
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
HIP association, prior to communications. It also defines a packet HIP association, prior to communications. It also defines a packet
format and procedures for updating an active HIP association. Other format and procedures for updating an active HIP association. Other
elements of the HIP architecture are specified in other documents, elements of the HIP architecture are specified in other documents,
such as. such as.
o "Using the Encapsulating Security Payload (ESP) Transport Format o "Using the Encapsulating Security Payload (ESP) Transport Format
with the Host Identity Protocol (HIP)" [RFC5202]: how to use the with the Host Identity Protocol (HIP)" [I-D.ietf-hip-rfc5202-bis]:
Encapsulating Security Payload (ESP) for integrity protection and how to use the Encapsulating Security Payload (ESP) for integrity
optional encryption protection and optional encryption
o "End-Host Mobility and Multihoming with the Host Identity o "End-Host Mobility and Multihoming with the Host Identity
Protocol" [RFC5206]: how to support mobility and multihoming in Protocol" [I-D.ietf-hip-rfc5206-bis]: how to support mobility and
HIP multihoming in HIP
o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions"
[RFC5205]: how to extend DNS to contain Host Identity information [I-D.ietf-hip-rfc5205-bis]: how to extend DNS to contain Host
Identity information
o "Host Identity Protocol (HIP) Rendezvous Extension" [RFC5204]: o "Host Identity Protocol (HIP) Rendezvous Extension"
using a rendezvous mechanism to contact mobile HIP hosts [I-D.ietf-hip-rfc5204-bis]: using a rendezvous mechanism to
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 switch from one That is it should be a part of the protocol to switch from one
cryptographic primitive to another, and reasonable effort should be cryptographic primitive to another, and reasonable effort should be
done to support a reasonable set of mainstream algorithms. This done to support a reasonable set of mainstream algorithms. This
update to the Base Exchange adds this needed cryptographic agility update to the Base Exchange includes this needed cryptographic
while addressing the downgrade attacks that such flexibility enables. agility while addressing the downgrade attacks that such flexibility
In particular, Elliptic Curve support (ECDSA and ECDH) and introduces. In particular, Elliptic Curve support (ECDSA and ECDH)
alternative hash functions have been added. and alternative hash functions have been 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
explained in the HIP architecture description [rfc4423-bis]. explained in the HIP architecture description
[I-D.ietf-hip-rfc4423-bis].
There are two main representations of the Host Identity, the full There are two main representations of the Host Identity, the full
Host Identifier (HI) and the Host Identity Tag (HIT). The HI is a Host Identifier (HI) and the Host Identity Tag (HIT). The HI is a
public key and directly represents the Identity. Since there are public key and directly represents the Identity. Since there are
different public key algorithms that can be used with different key different public key algorithms that can be used with different key
lengths, the HI is not good for use as a packet identifier, or as an lengths, the HI is unsuitable for use as a packet identifier, or as
index into the various operational tables needed to support HIP. an index into the various state-related implementation structures
Consequently, a hash of the HI, the Host Identity Tag (HIT), becomes needed to support HIP. Consequently, a hash of the HI, the Host
the operational representation. It is 128 bits long and is used in Identity Tag (HIT), is the operational representation. It is 128
the HIP payloads and to index the corresponding state in the end bits long and is used in the HIP headers and to index the
hosts. The HIT has an important security property in that it is corresponding state in the end hosts. The HIT has an important
self-certifying (see Section 3). security property in that it is self-certifying (see Section 3).
1.2. The HIP Base Exchange (BEX) 1.2. The HIP Base Exchange (BEX)
The HIP base exchange is a two-party cryptographic protocol used to The HIP base exchange is a two-party cryptographic protocol used to
establish communications context between hosts. The base exchange is establish communications context between hosts. The base exchange is
a SIGMA-compliant [KRA03] four-packet exchange. The first party is a SIGMA-compliant [KRA03] four-packet exchange. The first party is
called the Initiator and the second party the Responder. The four- called the Initiator and the second party the Responder. The
packet design helps to make HIP DoS resilient. The protocol protocol exchanges Diffie-Hellman keys in the 2nd and 3rd packets,
exchanges Diffie-Hellman keys in the 2nd and 3rd packets, and and authenticates the parties in the 3rd and 4th packets. The four-
authenticates the parties in the 3rd and 4th packets. Additionally, packet design helps to make HIP DoS resilient. It allows the
the Responder starts a puzzle exchange in the 2nd packet, with the Responder to stay stateless until the IP address and the a
Initiator completing it in the 3rd packet before the Responder stores cryptographic puzzle is verified. The Responder starts the puzzle
any state from the exchange. exchange in the 2nd packet, with the Initiator completing it in the
3rd packet before the Responder stores any state from the exchange.
The exchange can use the Diffie-Hellman output to encrypt the Host The exchange can use the Diffie-Hellman output to encrypt the Host
Identity of the Initiator in the 3rd packet (although Aura, et al., Identity of the Initiator in the 3rd packet (although Aura, et al.,
[AUR03] notes that such operation may interfere with packet- [AUR03] notes that such operation may interfere with packet-
inspecting middleboxes), or the Host Identity may instead be sent inspecting middleboxes), or the Host Identity may instead be sent
unencrypted. The Responder's Host Identity is not protected. It unencrypted. The Responder's Host Identity is not protected. It
should be noted, however, that both the Initiator's and the should be noted, however, that both the Initiator's and the
Responder's HITs are transported as such (in cleartext) in the Responder's HITs are transported as such (in cleartext) in the
packets, allowing an eavesdropper with a priori knowledge about the packets, allowing an eavesdropper with a priori knowledge about the
parties to verify their identities. parties to identify them by their HITs. Hence, encrypting the HI of
any party does not provide privacy against such attacker.
Data packets start to flow after the 4th packet. The 3rd and 4th HIP Data packets start to flow after the 4th packet. The 3rd and 4th HIP
packets may carry a data payload in the future. However, the details packets may carry a data payload in the future. However, the details
of this may be defined later. of this may be defined later.
An existing HIP association can be updated using the update mechanism An existing HIP association can be updated using the update mechanism
defined in this document, and when the association is no longer defined in this document, and when the association is no longer
needed, it can be closed using the defined closing mechanism. needed, it can be closed using the defined closing mechanism.
Finally, HIP is designed as an end-to-end authentication and key Finally, HIP is designed as an end-to-end authentication and key
establishment protocol, to be used with Encapsulated Security Payload establishment protocol, to be used with Encapsulated Security Payload
(ESP) [RFC5202] and other end-to-end security protocols. The base (ESP) [I-D.ietf-hip-rfc5202-bis] and other end-to-end security
protocol does not cover all the fine-grained policy control found in protocols. The base protocol does not cover all the fine-grained
Internet Key Exchange (IKE) [RFC4306] that allows IKE to support policy control found in Internet Key Exchange (IKE) [RFC4306] that
complex gateway policies. Thus, HIP is not a replacement for IKE. allows IKE to support complex gateway policies. Thus, HIP is not a
complete replacement for IKE.
1.3. Memo Structure 1.3. Memo Structure
The rest of this memo is structured as follows. Section 2 defines The rest of this memo is structured as follows. Section 2 defines
the central keywords, notation, and terms used throughout the rest of the central keywords, notation, and terms used throughout the rest of
the document. Section 3 defines the structure of the Host Identity the document. Section 3 defines the structure of the Host Identity
and its various representations. Section 4 gives an overview of the and its various representations. Section 4 gives an overview of the
HIP base exchange protocol. Sections 5 and 6 define the detail HIP base exchange protocol. Sections 5 and 6 define the detail
packet formats and rules for packet processing. Finally, Sections 7, packet formats and rules for packet processing. Finally, Sections 7,
9, and 10 discuss policy, security, and IANA considerations, 9, and 10 discuss policy, security, and IANA considerations,
skipping to change at page 9, line 30 skipping to change at page 9, line 38
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
(c.f. Appendix E). (c.f. Appendix E).
Length of the Responder's HIT Hash Algorithm (RHASH_len): RHASH_len Length of the Responder's HIT Hash Algorithm (RHASH_len): RHASH_len
is the natural output length of RHASH in bits. is the natural output length of RHASH in bits.
3. Host Identifier (HI) and Its Structure 3. Host Identifier (HI) and its Structure
In this section, the properties of the Host Identifier and Host In this section, the properties of the Host Identifier and Host
Identifier Tag are discussed, and the exact format for them is Identifier Tag are discussed, and the exact format for them is
defined. In HIP, the public key of an asymmetric key pair is used as defined. In HIP, the public key of an asymmetric key pair is used as
the Host Identifier (HI). Correspondingly, the host itself is the Host Identifier (HI). Correspondingly, the host itself is
defined as the entity that holds the private key from the key pair. defined as the entity that holds the private key of the key pair.
See the HIP architecture specification [rfc4423-bis] for more details See the HIP architecture specification [I-D.ietf-hip-rfc4423-bis] for
about the difference between an identity and the corresponding more details on the difference between an identity and the
identifier. corresponding identifier.
HIP implementations MUST support the Rivest Shamir Adelman (RSA) HIP implementations MUST support the Rivest Shamir Adelman (RSA)
[RFC3110] public key algorithm, and SHOULD support the Digital [RFC3110] public key algorithm, and SHOULD support the Digital
Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve
Digital Signature Algorithm (ECDSA) Section 5.2.8, ECDSA description; Digital Signature Algorithm (ECDSA) defined in Section 5.2.8. Other
other algorithms MAY be supported. algorithms MAY be supported.
A hashed encoding of the HI, the Host Identity Tag (HIT), is used in A hashed encoding of the HI, the Host Identity Tag (HIT), is used in
protocols to represent the Host Identity. The HIT is 128 bits long protocols to represent the Host Identity. The HIT is 128 bits long
and has the following three key properties: i) it is the same length and has the following three key properties: i) it is the same length
as an IPv6 address and can be used in address-sized fields in APIs as an IPv6 address and can be used in fixed address-sized fields in
and protocols, ii) it is self-certifying (i.e., given a HIT, it is APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it
computationally hard to find a Host Identity key that matches the is computationally hard to find a Host Identity key that matches the
HIT), and iii) the probability of HIT collision between two hosts is HIT), and iii) the probability of a HIT collision between two hosts
very low, hence, it is infeasible for an attacker to find a collision is very low, hence, it is infeasible for an attacker to find a
with a HIT that is in use. For details on the security properties of collision with a HIT that is in use. For details on the security
the HIT see [rfc4423-bis]. properties of the HIT see [I-D.ietf-hip-rfc4423-bis].
The structure of the HIT is defined in [RFC4843-bis]. The HIT The structure of the HIT is defined in [I-D.ietf-hip-rfc4843-bis].
consists of three parts: first, an IANA assigned prefix to The HIT consists of three parts: first, an IANA assigned prefix to
distinguish it from other IPv6 addresses. Second, a four-bit distinguish it from other IPv6 addresses. Second, a four-bit
encoding of the algorithms that were used for generating the HI and encoding of the algorithms that were used for generating the HI and
the hashed representation of HI. Third, a 96-bit hashed the hashed representation of HI. Third, a 96-bit hashed
representation of the Host Identity. The encoding of the ORCHID representation of the Host Identity. The encoding of the ORCHID
generation algorithm and the exact algorithm for generating the generation algorithm and the exact algorithm for generating the
hashed representation is specified in Appendix E. hashed representation is specified in Appendix E.
Carrying HIs and HITs in the header of user data packets would Carrying HIs and HITs in the header of user data packets would
increase the overhead of packets. Thus, it is not expected that they increase the overhead of packets. Thus, it is not expected that they
are carried in every packet, but other methods are used to map the are carried in every packet, but other methods are used to map the
data packets to the corresponding HIs. In some cases, this makes it data packets to the corresponding HIs. In some cases, this makes it
possible to use HIP without any additional headers in the user data possible to use HIP without any additional headers in the user data
packets. For example, if ESP is used to protect data traffic, the packets. For example, if ESP is used to protect data traffic, the
Security Parameter Index (SPI) carried in the ESP header can be used Security Parameter Index (SPI) carried in the ESP header can be used
to map the encrypted data packet to the correct HIP association. to map the encrypted data packet to the correct HIP association.
3.1. Host Identity Tag (HIT) 3.1. Host Identity Tag (HIT)
The Host Identity Tag is a 128-bit value -- a hashed encoding of the The Host Identity Tag is a 128-bit value -- a hashed encoding of the
Host Identifier. There are two advantages of using a hashed encoding Host Identifier. There are two advantages of using a hashed encoding
over the actual Host Identity public key in protocols. Firstly, its over the actual variable-sized Host Identity public key in protocols.
fixed length makes for easier protocol coding and also better manages Firstly, the fixed length of the HIT eases protocol coding and also
the packet size cost of this technology. Secondly, it presents a manages better the packet size cost of this technology. Secondly, it
consistent format to the protocol whatever underlying identity presents a consistent format to the protocol, independently of the
technology is used. underlying identity technology used.
RFC 4843-bis [RFC4843-bis] specifies 128-bit hash-based identifiers, RFC 4843-bis [I-D.ietf-hip-rfc4843-bis] specifies 128-bit hash-based
called Overlay Routable Cryptographic Hash Identifiers (ORCHIDs). identifiers, called Overlay Routable Cryptographic Hash Identifiers
Their prefix, allocated from the IPv6 address block, is defined in (ORCHIDs). Their prefix, allocated from the IPv6 address block, is
[RFC4843-bis]. The Host Identity Tag is a type of ORCHID. defined in [I-D.ietf-hip-rfc4843-bis]. The Host Identity Tag is one
type of an ORCHID.
This document extends [RFC5201] with measures to support crypto This document extends [RFC5201] with measures to support crypto
agility. One of these measures is to allow for different hash agility. One of these measures is to allow different hash functions
functions for creating a HIT. HIT Suites group sets of algorithms for creating a HIT. HIT Suites group the sets of algorithms that are
that are required to generate and use a particular HIT. The Suites required to generate and use a particular HIT. The Suites are
are encoded in HIT Suite IDs. These HIT Suite IDs are transmitted in encoded in HIT Suite IDs. These HIT Suite IDs are transmitted in the
the ORCHID Generation Algorithm field in the ORCHID. The HIT Suite ORCHID Generation Algorithm (OGA) field in the ORCHID. With the HIT
ID in the OGA field enables a hosts tell from another host's HIT, Suite ID in the OGA field, a hosts can tell from another host's HIT,
whether it can successfully establish a HIP association with that whether it supports the necessary hash and signature algorithms to
host. establish a 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 [RFC4843-bis] using a context ID value of 0xF0EF F02F described in [I-D.ietf-hip-rfc4843-bis] using a context ID value of
BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been generated 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been
randomly by the editor of this specification), and an input that generated randomly by the editor of this specification), and an input
encodes the Host Identity field (see Section 5.2.8) present in a HIP that encodes the Host Identity field (see Section 5.2.8) present in a
payload packet. The class of hash function, signature algorithm, and HIP payload packet. The set of hash function, signature algorithm,
the algorithm used for generating the HIT from the HI depends on the and the algorithm used for generating the HIT from the HI depends on
HIT Suite (see Appendix E) and is indicated by the four bits of the the HIT Suite (see Appendix E) and is indicated by the four bits of
Orchid Generation Algorithm (OGA) field in the ORCHID. Currently, the Orchid Generation Algorithm (OGA) field in the ORCHID.
truncated SHA-1 [FIPS.95-1.1993] and truncated SHA-256 Currently, truncated SHA-1 [FIPS.95-1.1993] and truncated SHA-256
[FIPS.180-2.2002] are defined as hashes for generating a HIT. [FIPS.180-2.2002] are defined as hashes for generating a HIT.
For Identities that are either RSA, Digital Signature Algorithm For Identities that are either RSA, Digital Signature Algorithm
(DSA), or Elliptic Curve DSA (ECDSA) public keys, the ORCHID input (DSA), or Elliptic Curve DSA (ECDSA) public keys, the ORCHID input
consists of the public key encoding as specified in the corresponding consists of the public key encoding as specified in the Section
DNSSEC documents, taking the algorithm-specific portion of the RDATA Section 5.2.8. This document defines four Algorithm profiles: RSA,
part of the KEY RR. There are currently only two defined public key DSA, ECDSA, and ECDSA_LOW. The ECDSA_LOW profile is meant for
algorithms: RSA/SHA-1 and DSA. Hence, either of the following devices with low computational capabilities. There are currently
applies: only three defined public key algorithm classes: RSA/SHA-1, DSA, and
ECDSA. Hence, either of the following applies:
The RSA public key is encoded as defined in [RFC3110] Section 2, The RSA public key is encoded as defined in [RFC3110] Section 2,
taking the exponent length (e_len), exponent (e), and modulus (n) taking the exponent length (e_len), exponent (e), and modulus (n)
fields concatenated. The length (n_len) of the modulus (n) can be fields concatenated. The length (n_len) of the modulus (n) can be
determined from the total HI Length and the preceding HI fields determined from the total HI Length and the preceding HI fields
including the exponent (e). Thus, the data that serves as input including the exponent (e). Thus, the data that serves as input
for the HIT generation has the same length as the HI. The fields for the HIT generation has the same length as the HI. The fields
MUST be encoded in network byte order, as defined in [RFC3110]. MUST be encoded in network byte order, as defined in [RFC3110].
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. Thus, the data taking the fields T, Q, P, G, and Y, concatenated as input. Thus,
to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, where T the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long,
is the size parameter as defined in [RFC2536]. The size parameter where T is the size parameter as defined in [RFC2536]. The size
T, affecting the field lengths, MUST be selected as the minimum parameter T, affecting the field lengths, MUST be selected as the
value that is long enough to accommodate P, G, and Y. The fields minimum value that is long enough to accommodate P, G, and Y. The
MUST be encoded in network byte order, as defined in [RFC2536]. fields MUST be encoded in network byte order, as defined in
[RFC2536].
The ECDSA public key is encoded as defined in [fundamental-ecc] The ECDSA public keys are encoded as defined in
Section 4.2 and 6. [I-D.mcgrew-fundamental-ecc] 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
The following material is an overview of the HIP protocol operation, This section is a simplified overview of the HIP protocol operation,
and does not contain all details of the packet formats or the packet and does not contain all the details of the packet formats or the
processing steps. Sections 5 and 6 describe in more detail the packet processing steps. Sections 5 and 6 describe in more detail
packet formats and packet processing steps, respectively, and are the packet formats and packet processing steps, respectively, and are
normative in case of any conflicts with this section. normative in case of any conflicts with this section.
The protocol number 139 has been assigned by IANA to the Host The protocol number 139 has been assigned by IANA to the Host
Identity Protocol. Identity Protocol.
The HIP payload (Section 5.1) header could be carried in every IP The HIP payload (Section 5.1) header could be carried in every IP
datagram. However, since HIP headers are relatively large (40 datagram. However, since HIP headers are relatively large (40
bytes), it is desirable to 'compress' the HIP header so that the HIP bytes), it is desirable to 'compress' the HIP header so that the HIP
header only occurs in control packets used to establish or change HIP header only occurs in control packets used to establish or change HIP
association state. The actual method for header 'compression' and association state. The actual method for header 'compression' and
for matching data packets with existing HIP associations (if any) is for matching data packets with existing HIP associations (if any) is
defined in separate documents, describing transport formats and defined in separate documents, describing transport formats and
methods. All HIP implementations MUST implement, at minimum, the ESP methods. All HIP implementations MUST implement, at minimum, the ESP
transport format for HIP [RFC5202]. transport format for HIP [I-D.ietf-hip-rfc5202-bis].
4.1. Creating a HIP Association 4.1. Creating a HIP Association
By definition, the system initiating a HIP exchange is the Initiator, By definition, the system initiating a HIP exchange is the Initiator,
and the peer is the Responder. This distinction is forgotten once and the peer is the Responder. This distinction is forgotten once
the base exchange completes, and either party can become the the base exchange completes, and either party can become the
Initiator in future communications. Initiator in future communications.
The HIP base exchange serves to manage the establishment of state The HIP base exchange serves to manage the establishment of state
between an Initiator and a Responder. The first packet, I1, between an Initiator and a Responder. The first packet, I1,
initiates the exchange, and the last three packets, R1, I2, and R2, initiates the exchange, and the last three packets, R1, I2, and R2,
constitute an authenticated Diffie-Hellman [DIF76] key exchange for constitute an authenticated Diffie-Hellman [DIF76] key exchange for
session key generation. In the first two packets, the hosts agree on session-key generation. In the first two packets, the hosts agree on
a set of cryptographic identifiers and algorithms that then are used a set of cryptographic identifiers and algorithms that are then used
in and after the exchange. During the Diffie-Hellman key exchange, a in and after the exchange. During the Diffie-Hellman key exchange, a
piece of keying material is generated. The HIP association keys are piece of keying material is generated. The HIP association keys are
drawn from this keying material. If other cryptographic keys are drawn from this keying material. If other cryptographic keys are
needed, e.g., to be used with ESP, they are expected to be drawn from needed, e.g., to be used with ESP, they are expected to be drawn from
the same keying material. the same keying material.
The Initiator first sends a trigger packet, I1, to the Responder. The Initiator first sends a trigger packet, I1, to the Responder.
The packet contains the HIT of the Initiator and possibly the HIT of The packet contains the HIT of the Initiator and possibly the HIT of
the Responder, if it is known. Moreover, the I1 packet initializes the Responder, if it is known. Moreover, the I1 packet initializes
the negotiation of the Diffie-Hellman group that is used for the negotiation of the Diffie-Hellman group that is used for
generating the keying material. Therefore, the I1 contains a list of generating the keying material. Therefore, the I1 packet contains a
Diffie Hellman Group IDs supported by the Initiator. Note that in list of Diffie Hellman Group IDs supported by the Initiator. Note
some cases it may be possible to replace this trigger packet by some that in some cases it may be possible to replace this trigger packet
other form of a trigger, in which case the protocol starts with the by some other form of a trigger, in which case the protocol starts
Responder sending the R1 packet. In such cases, another mechanism to with the Responder sending the R1 packet. In such cases, another
convey the Initiator's supported DH Groups (e.g., by using a default mechanism to convey the Initiator's supported DH Groups (e.g., by
group) must be specified. using a default group) must be specified.
The second packet, R1, starts the actual authenticated Diffie-Hellman The second packet, R1, starts the actual authenticated Diffie-Hellman
exchange. It contains a puzzle -- a cryptographic challenge that the exchange. It contains a puzzle -- a cryptographic challenge that the
Initiator must solve before continuing the exchange. The level of Initiator must solve before continuing the exchange. The level of
difficulty of the puzzle can be adjusted based on level of trust with difficulty of the puzzle can be adjusted based on level of trust with
the Initiator, current load, or other factors. In addition, the R1 the Initiator, current load, or other factors. In addition, the R1
contains the Responder's Diffie-Hellman parameter and lists of contains the Responder's Diffie-Hellman parameter and lists of
cryptographic algorithms supported by the Responder. Based on these cryptographic algorithms supported by the Responder. Based on these
lists, the Initiator can continue, abort, or restart the base lists, the Initiator can continue, abort, or restart the base
exchange with a different selection of cryptographic algorithms. The exchange with a different selection of cryptographic algorithms.
R1 packet contains a signature that covers selected parts of the Also, the R1 packet contains a signature that covers selected parts
message. Some fields are left outside the signature to support pre- of the message. Some fields are left outside the signature to
created R1s. support pre-created R1s.
In the I2 packet, the Initiator must display the solution to the In the I2 packet, the Initiator must display the solution to the
received puzzle. Without a correct solution, the I2 message is received puzzle. Without a correct solution, the I2 message is
discarded. The I2 also contains a Diffie-Hellman parameter that discarded. The I2 packet also contains a Diffie-Hellman parameter
carries needed information for the Responder. The packet is signed that carries needed information for the Responder. The packet is
by the sender. signed by the Initiator.
The R2 packet acknowledges the receipt of the I2 and finalizes the The R2 packet acknowledges the receipt of the I2 packet and completes
base exchange. The packet is signed. the base exchange. The packet is signed by the Responder.
The base exchange is illustrated below. The term "key" refers to the The base exchange is illustrated below. The term "key" refers to the
Host Identity public key, and "sig" represents a signature using such Host Identity public key, and "sig" represents a signature using such
a key. The packets contain other parameters not shown in this a key. The packets contain other parameters not shown in this
figure. figure.
Initiator Responder Initiator Responder
I1: DH list I1: DH list
--------------------------> -------------------------->
skipping to change at page 14, line 9 skipping to change at page 14, line 26
compute DH check puzzle compute DH check puzzle
check sig check sig
R2: sig R2: sig
<-------------------------- <--------------------------
check sig compute DH check sig compute DH
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 I2. Furthermore, the puzzle to delay state creation until receiving the I2 packet. Furthermore,
allows the Responder to use a fairly cheap calculation to check that the puzzle allows the Responder to use a fairly cheap calculation to
the Initiator is "sincere" in the sense that it has churned CPU check that the Initiator is "sincere" in the sense that it has
cycles in solving the puzzle. churned enough CPU cycles in solving the puzzle.
The puzzle mechanism has been explicitly designed to give space for The puzzle mechanism has been explicitly designed to give space for
various implementation options. It allows a Responder implementation various implementation options. First, it allows a Responder
to completely delay session-specific state creation until a valid I2 implementation to completely delay session-specific state creation
is received. In such a case, a correctly formatted I2 can be until a valid I2 packet is received. In such a case, a correctly
rejected only once the Responder has checked its validity by formatted I2 packet can be rejected immediately once the Responder
computing one hash function. On the other hand, the design also has checked its validity by computing only one hash function.
allows a Responder implementation to keep state about received I1s, Second, hand, the design also allows a Responder implementation to
and match the received I2s against the state, thereby allowing the keep state about received I1 packets, and match the received I2
implementation to avoid the computational cost of the hash function. packets against the state, thereby allowing the implementation to
The drawback of this latter approach is the requirement of creating avoid the computational cost of the hash function. The drawback of
state. Finally, it also allows an implementation to use other this second approach is the requirement of creating state. Finally,
combinations of the space-saving and computation-saving mechanisms. it also allows an implementation to use other combinations of the
space-saving and computation-saving mechanisms.
The Responder can remain stateless and drop most spoofed I2s because The Responder can remain stateless and drop most spoofed I2 packets
puzzle calculation is based on the Initiator's Host Identity Tag. The because puzzle calculation is based on the Initiator's Host Identity
idea is that the Responder has a (perhaps varying) number of pre- Tag. The idea is that the Responder has a (perhaps varying) number of
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
information carried in I1. When the Responder then later receives information carried in the I1 packet. When the Responder then later
I2, it can verify that the puzzle has been solved using the receives the I2 packet, it can verify that the puzzle has been solved
Initiator's HIT. This makes it impractical for the attacker to first using the Initiator's HIT. This makes it impractical for the
exchange one I1/R1, and then generate a large number of spoofed I2s attacker to first exchange one I1/R1 packet, and then generate a
that seemingly come from different HITs. The method does not protect large number of spoofed I2 packets that seemingly come from different
from an attacker that uses fixed HITs, though. Against such an HITs. This method does not protect the Responder from an attacker
attacker a viable approach may be to create a piece of local state, that uses fixed HITs, though. Against such an attacker, a viable
and remember that the puzzle check has previously failed. See approach may be to create a piece of local state, and remember that
Appendix A for one possible implementation. Implementations SHOULD the puzzle check has previously failed. See Appendix A for one
include sufficient randomness to the algorithm so that algorithmic possible implementation. Responder implementations SHOULD include
sufficient randomness in the puzzle values so that algorithmic
complexity attacks become impossible [CRO03]. complexity attacks become impossible [CRO03].
The Responder can set the puzzle difficulty for Initiator, based on The Responder can set the puzzle difficulty for the Initiator, based
its level of trust of the Initiator. Because the puzzle is not on its level of trust of the Initiator. Because the puzzle is not
included in the signature calculation, the Responder can use pre- included in the signature calculation, the Responder can use pre-
calculated R1 packets and include the puzzle just before sending the calculated R1 packets and include the puzzle just before sending the
R1 to the Initiator. The Responder SHOULD use heuristics to R1 to the Initiator. The Responder SHOULD use heuristics to
determine when it is under a denial-of-service attack, and set the determine when it is under a denial-of-service attack, and set the
puzzle difficulty value K appropriately; see below. puzzle difficulty value K appropriately as explained later.
4.1.2. Puzzle Exchange 4.1.2. Puzzle Exchange
The Responder starts the puzzle exchange when it receives an I1. The The Responder starts the puzzle exchange when it receives an I1
Responder supplies a random number I, and requires the Initiator to packet. The Responder supplies a random number I, and requires the
find a number J. To select a proper J, the Initiator must create the Initiator to find a number J. To select a proper J, the Initiator
concatenation of I, the HITs of the parties, and J, and take a hash must create the concatenation of I, the HITs of the parties, and J,
over this concatenation using the RHASH algorithm. The lowest order and calculate a hash over this concatenation using the RHASH
K bits of the result MUST be zeros. The value K sets the difficulty algorithm. The lowest order K bits of the result MUST be zeros. The
of the puzzle. value K sets the difficulty of the puzzle.
To generate a proper number J, the Initiator will have to generate a To generate a proper number J, the Initiator will have to generate a
number of Js until one produces the hash target of zeros. The number of Js until one produces the hash target of zeros. The
Initiator SHOULD give up after exceeding the puzzle lifetime in the Initiator SHOULD give up after exceeding the puzzle lifetime in the
PUZZLE parameter (Section 5.2.4). The Responder needs to re-create PUZZLE parameter (as described in Section 5.2.4). The Responder
the concatenation of I, the HITs, and the provided J, and compute the needs to re-create the concatenation of I, the HITs, and the provided
hash once to prove that the Initiator did its assigned task. J, and compute the hash once to prove that the Initiator completed
its assigned task.
To prevent precomputation attacks, the Responder MUST select the To prevent precomputation attacks, the Responder MUST select the
number I in such a way that the Initiator cannot guess it. number I in such a way that the Initiator cannot guess it.
Furthermore, the construction MUST allow the Responder to verify that Furthermore, the construction MUST allow the Responder to verify that
the value I was indeed selected by it and not by the Initiator. See the value I was indeed selected by it and not by the Initiator. See
Appendix A for an example on how to implement this. Appendix A for an example on how to implement this.
Using the Opaque data field in the PUZZLE (Section 5.2.4), in an Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an
ECHO_REQUEST_SIGNED (Section 5.2.19) or in an ECHO_REQUEST_UNSIGNED ECHO_REQUEST_SIGNED (see Section 5.2.19) or in an
parameter (Section 5.2.20), the Responder can include some data in R1 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.20), the Responder
that the Initiator must copy unmodified in the corresponding I2 can include some data in R1 that the Initiator MUST copy unmodified
packet. The Responder can generate the Opaque data in various ways; in the corresponding I2 packet. The Responder can use the opaque
e.g., using encryption or hashing with some secret, the sent I, and data to transfer a piece of local state information to the Initiator
possibly other related data. Using the same secret, the received I and back, for example to recognize that the I2 is a response to a
(from the I2), and the other related data (if any), the Receiver can previously sent R1. The Responder can generate the Opaque data in
verify that it has itself sent the I to the Initiator. The Responder various ways; e.g., using encryption or hashing with some secret, the
MUST periodically change such a used secret. sent I, and possibly using other related data. With the same secret,
the received I (from the I2 packet), and the other related data (if
any), the Receiver can verify that it has itself sent the I to the
Initiator. The Responder MUST periodically change such a secret.
It is RECOMMENDED that the Responder generates new secrets for the It is RECOMMENDED that the Responder generates new secrets for the
puzzle and new R1s once every few minutes. Furthermore, it is puzzle and new R1s once every few minutes. Furthermore, it is
RECOMMENDED that the Responder is able to verify valid puzzle RECOMMENDED that the Responder is able to verify valid puzzle
solution at least Lifetime seconds after the puzzle secret has been solution at least Lifetime seconds after the puzzle secret has been
deprecated. These time values guarantee that the puzzle is valid for deprecated. This time value guarantees that the puzzle is valid for
at least Lifetime and at most 2*Lifetime seconds. This limits the at least Lifetime and at most 2*Lifetime seconds. This limits the
usability that an old, solved puzzle has to an attacker. usability of an old, solved puzzle has to an attacker. Moreover, it
avoids problems with the validity of puzzles if the lifetime is
relatively short compared to the network delay and the time for
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 (Section 6.5). keying material from the Diffie Hellman key exchange (see
Therefore, a Responder SHOULD NOT use the same puzzle I with the same Section 6.5). Therefore, a Responder SHOULD NOT use the same puzzle
DH keys for the same Initiator twice to ensure that the derived I with the same DH keys for the same Initiator twice to ensure that
keying material differs. Such uniqueness can be achieved, for the derived keying material differs. Such uniqueness can be
example, by using a counter as additional input for generating I. achieved, for example, by using a counter as an additional input for
generating I. This counter can be increased for each processed I1
This counter can be increased for each processed I1 packet. The packet. The state of the counter can be transmitted in the Opaque
state of the counter can be transmitted in the Opaque data field in data field in the PUZZLE (see Section 5.2.4), in an
the PUZZLE (Section 5.2.4), in an ECHO_REQUEST_SIGNED ECHO_REQUEST_SIGNED (see Section 5.2.19) or in an
(Section 5.2.19) or in an ECHO_REQUEST_UNSIGNED parameter ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.20) without the need
(Section 5.2.20) 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. attacks. The decision was to NOT include a timestamp to avoid
problems with global time synchronization.
NOTE: The protocol developers explicitly considered whether a memory NOTE: The protocol developers explicitly considered whether a memory
bound function should be used for the puzzle instead of a CPU-bound bound function should be used for the puzzle instead of a CPU-bound
function. The decision was not to use memory-bound functions. At function. The decision was not to use memory-bound functions.
the time of the decision, the idea of memory-bound functions was
relatively new and their IPR status were unknown. Once there is more
experience about memory-bound functions and once their IPR status is
better known, it may be reasonable to reconsider this decision.
4.1.3. Authenticated Diffie-Hellman Protocol with DH Group Negotiation 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group Negotiation
The packets R1, I2, and R2 implement a standard authenticated Diffie- The packets R1, I2, and R2 implement a standard authenticated Diffie-
Hellman exchange. The Responder sends one of its public Diffie- Hellman exchange. The Responder sends one of its public Diffie-
Hellman keys and its public authentication key, i.e., its Host Hellman keys and its public authentication key, i.e., its Host
Identity, in R1. The signature in R1 allows the Initiator to verify Identity, in R1. The signature in the R1 packet allows the Initiator
that the R1 has been once generated by the Responder. However, since to verify that the R1 has been once generated by the Responder.
it is precomputed and therefore does not cover association-specific
information in the I1 packet, it does not protect from replay However, since it is precomputed and therefore does not cover
attacks. association-specific information in the I1 packet, it does not
protect from replay attacks.
Before the actual authenticated Diffie-Hellman exchange, the Before the actual authenticated Diffie-Hellman exchange, the
Initiator expresses its preference regarding its choice of the DH Initiator expresses its preference regarding its choice of the DH
groups in the I1 packet. The preference is expressed as a sorted groups in the I1 packet. The preference is expressed as a sorted
list of DH Group IDs. The I1 packet is not protected by a signature. list of DH Group IDs. The I1 packet is not protected by a signature.
Therefore, this list is sent in an unauthenticated way to avoid Therefore, this list is sent in an unauthenticated way to avoid
costly computations for processing the I1 packet on the Responder's costly computations for processing the I1 packet at the Responder
side. Based on the preferences of the Initiator, the Responder sends side. Based on the preferences of the Initiator, the Responder sends
an R1 packet containing its most suitable public DH value. It also an R1 packet containing its most suitable public DH value. The
attaches a list of its own preferences to the R1 to convey the basis Responder also attaches a list of its own preferences to the R1 to
for the DH group selection to the Initiator. convey the basis for the DH group selection to the Initiator. This
list is carried in the signed part of the R1 packet. If the choice
of the DH group value in the R1 does not match the preferences of the
Initiator and the Responder, the Initiator can detect that the list
of DH Group IDs in the I1 was manipulated (see below for details).
If none of the DH Group IDs in the I1 is supported by the Responder, If none of the DH Group IDs in the I1 packet is supported by the
the Responder selects the DH Group most suitable for it regardless of Responder, the Responder selects the DH Group most suitable for it
the Initiator's preference. It then sends the R1 containing this DH regardless of the Initiator's preference. It then sends the R1
Group and its list of supported DH Group IDs to the Initiator. containing this DH Group and its list of supported DH Group IDs to
the Initiator.
When the Initiator receives an R1, it gets one of the Responder's When the Initiator receives an R1, it receives one of the Responder's
public Diffie-Hellman values and the list of DH Group IDs supported public Diffie-Hellman values and the list of DH Group IDs supported
by the Responder. This list is covered by the signature in the R1 by the Responder. This list is covered by the signature in the R1
packet to avoid forgery. The Initiator compares the Group ID of the packet to avoid forgery. The Initiator compares the Group ID of the
public DH value in the R1 packet to the list of supported DH Group public DH value in the R1 packet to the list of supported DH Group
IDs in the R1 packets and to its own preferences expressed in the IDs in the R1 packets and to its own preferences expressed in the
list of supported DH Group IDs. The Initiator continues the BEX only list of supported DH Group IDs. The Initiator continues the BEX only
if the Group ID of the public DH value of the Responder matches the if the Group ID of the public DH value of the Responder intersects
preferences of both Initiator and Responder. Otherwise, the the preferences of both Initiator and Responder. Otherwise, the
communication is subject of a downgrade attack and the Initiator must communication is subject of a downgrade attack and the Initiator MUST
restart the key exchange with a new I1 packet or must abort the key either restart the key exchange with a new I1 packet or abort the key
exchange. If the Responder's choice of the DH Group is not supported exchange. If the Responder's choice of the DH Group is not supported
by the Initiator, the Initiator may abort the handshake or send a new by the Initiator, the Initiator MAY abort the handshake or send a new
I1 with a different list of supported DH Groups. However, the I1 packet with a different list of supported DH Groups. However, the
Initiator MUST verify the signature of the R1 packet before Initiator MUST verify the signature of the R1 packet before
restarting or aborting the handshake. It MUST silently ignore the R1 restarting or aborting the handshake. It MUST silently ignore the R1
packet if the signature is not valid. packet if the signature is not valid.
If the preferences regarding the DH Group ID match, the Initiator If the preferences regarding the DH Group ID match, the Initiator
computes the Diffie-Hellman session key (Kij). It creates a HIP computes the Diffie-Hellman session key (Kij). The Initiator creates
association using keying material from the session key (see a HIP association using keying material from the session key (see
Section 6.5), and may use the association to encrypt its public Section 6.5), and may use the HIP association to encrypt its public
authentication key, i.e., Host Identity. The resulting I2 contains authentication key, i.e., Host Identity. The resulting I2 packet
the Initiator's Diffie-Hellman key and its (optionally encrypted) contains the Initiator's Diffie-Hellman key and its (optionally
public authentication key. The signature in I2 covers all of the encrypted) public authentication key. The signature of the I2
packet. message covers all signed parameters of the packet without exceptions
as in the R1.
The Responder extracts the Initiator Diffie-Hellman public key from The Responder extracts the Initiator's Diffie-Hellman public key from
the I2, computes the Diffie-Hellman session key, creates a the I2 packet, computes the Diffie-Hellman session key, creates a
corresponding HIP association, and decrypts the Initiator's public corresponding HIP association, and decrypts the Initiator's public
authentication key. It can then verify the signature using the authentication key. It can then verify the signature using the
authentication key. authentication key.
The final message, R2, is needed to protect the Initiator from replay The final message, R2, completes the BEX and protects the Initiator
attacks. against replay attacks because the Responder uses the shared key from
the Diffie-Hellman exchange to create a HMAC as well as it uses the
private key of its Host Identity to sign the packet contents.
4.1.4. HIP Replay Protection 4.1.4. HIP Replay Protection
The HIP protocol includes the following mechanisms to protect against The HIP protocol includes the following mechanisms to protect against
malicious replays. Responders are protected against replays of I1 malicious packet replays. Responders are protected against replays
packets by virtue of the stateless response to I1s with presigned R1 of I1 packets by virtue of the stateless response to I1 packets with
messages. Initiators are protected against R1 replays by a presigned R1 messages. Initiators are protected against R1 replays
monotonically increasing "R1 generation counter" included in the R1. by a monotonically increasing "R1 generation counter" included in the
Responders are protected against replays or false I2s by the puzzle R1. Responders are protected against replays of forged I2 packets by
mechanism (Section 4.1.1 above), and optional use of opaque data. the puzzle mechanism (see Section 4.1.1 above), and optional use of
Hosts are protected against replays to R2s and UPDATEs by use of a opaque data. Hosts are protected against replays of R2 packets and
less expensive HMAC verification preceding HIP signature UPDATEs by use of a less expensive HMAC verification preceding the
verification. HIP signature verification.
The R1 generation counter is a monotonically increasing 64-bit The R1 generation counter is a monotonically increasing 64-bit
counter that may be initialized to any value. The scope of the counter that may be initialized to any value. The scope of the
counter MAY be system-wide but SHOULD be per Host Identity, if there counter MAY be system-wide but SHOULD be applied per Host Identity,
is more than one local host identity. The value of this counter if there is more than one local host identity. The value of this
SHOULD be kept across system reboots and invocations of the HIP base counter SHOULD be preserved across system reboots and invocations of
exchange. This counter indicates the current generation of puzzles. the HIP base exchange. This counter indicates the current generation
Implementations MUST accept puzzles from the current generation and of puzzles. Implementations MUST accept puzzles from the current
MAY accept puzzles from earlier generations. A system's local generation and MAY accept puzzles from earlier generations. A
counter MUST be incremented at least as often as every time old R1s system's local counter MUST be incremented at least as often as every
cease to be valid, and SHOULD never be decremented, lest the host time old R1s cease to be valid. The local counter SHOULD never be
expose its peers to the replay of previously generated, higher decremented, lest the host exposes its peers to the replay of
numbered R1s. The R1 counter SHOULD NOT roll over. previously generated, higher numbered R1s. The R1 counter SHOULD NOT
roll over.
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
I1s (Section 6.6.1) or due to a replay of an old R1. When sending I1 packets (see Section 6.6.1) or due to a replay of an old R1. When
multiple I1s, an Initiator SHOULD wait for a small amount of time (a sending multiple I1 packets, an Initiator SHOULD wait for a small
reasonable time may be 2 * expected RTT) after the first R1 reception amount of time (a reasonable time may be 2 * expected RTT) after the
to allow possibly multiple R1s to arrive, and it SHOULD respond to an first R1 reception to allow possibly multiple R1s to arrive, and it
R1 among the set with the largest R1 generation counter. If an SHOULD respond to an R1 among the set with the largest R1 generation
Initiator is processing an R1 or has already sent an I2 (still counter. If an Initiator is processing an R1 or has already sent an
waiting for R2) and it receives another R1 with a larger R1 I2 packet (still waiting for the R2 packet) and it receives another
generation counter, it MAY elect to restart R1 processing with the R1 with a larger R1 generation counter, it MAY elect to restart R1
fresher R1, as if it were the first R1 to arrive. processing with the fresher R1, as if it were the first R1 to arrive.
Upon conclusion of an active HIP association with another host, the Upon conclusion of an active HIP association with another host, the
R1 generation counter associated with the peer host SHOULD be R1 generation counter associated with the peer host SHOULD be
flushed. A local policy MAY override the default flushing of R1 flushed. A local policy MAY override the default flushing of R1
counters on a per-HIT basis. The reason for recommending the counters on a per-HIT basis. The reason for recommending the
flushing of this counter is that there may be hosts where the R1 flushing of this counter is that there may be hosts where the R1
generation counter (occasionally) decreases; e.g., due to hardware generation counter (occasionally) decreases; e.g., due to hardware
failure. failure.
4.1.5. Refusing a HIP Exchange 4.1.5. Refusing a HIP Exchange
A HIP-aware host may choose not to accept a HIP exchange. If the A HIP-aware host may choose not to accept a HIP exchange. If the
host's policy is to only be an Initiator, it should begin its own HIP host's policy is to only be an Initiator, it should begin its own HIP
exchange. A host MAY choose to have such a policy since only the exchange. A host MAY choose to have such a policy since only the
Initiator's HI is protected in the exchange. There is a risk of a privacy of the Initiator's HI is protected in the exchange. It
race condition if each host's policy is to only be an Initiator, at should be noted that such behavior can introduce the risk of a race
which point the HIP exchange will fail. condition if each host's policy is to only be an Initiator, at which
point the HIP 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 simple ICMP message. A HIP NOTIFY message is not used because no
HIP session exists between the two hosts at that time.
4.1.6. Aborting a HIP Exchange 4.1.6. Aborting a HIP 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 exchange because of insufficient suport for cryptographic a HIP 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.
The R1 packet contains a signed list of HIT Suite IDs supported by The R1 packet contains a signed list of HIT Suite IDs as supported by
the Responder. Therefore, the Initiator can determine whether its the Responder. Therefore, the Initiator can determine whether its
source HIT is supported by the Responder. If the HIT Suite ID of the source HIT is supported by the Responder. If the HIT Suite ID of the
Initiator's HIT is not contained in the list of HIT Suites, the Initiator's HIT is not contained in the list of HIT Suites in the R1,
Initiator MAY abort the handshake silently or MAY restart the the Initiator MAY abort the handshake silently or MAY restart the
handshake with a new I1 packet that contains a source HIT supported handshake with a new I1 packet that contains a source HIT supported
by the Responder. by the Responder.
During the Handshake, the Initiator and the Responder agree on a DH During the Handshake, the Initiator and the Responder agree on a
Group. The Responder selects the DH Group and its DH public value in single DH Group. The Responder selects the DH Group and its DH
the R1 based on the list of DH Suite IDs in the I1 packet. If the public value in the R1 based on the list of DH Suite IDs in the I1
responder supports none of the DH Groups selected by the Initiator, packet. If the responder supports none of the DH Groups requested by
the Responder selects an arbitrary DH and replies an R1 containing the Initiator, the Responder selects an arbitrary DH and replies with
its list of supported DH Group IDs. In this case, the Initiator will an R1 containing its list of supported DH Group IDs. In such case,
receive an R1 packet containing the DH public value for an the Initiator receives an R1 packet containing the DH public value
unsupported DH Group and the Responder's DH Group list in the signed for an unrequested DH Group and also the Responder's DH Group list in
part of the R1 packet. At this point, the Initiator MAY abort the the signed part of the R1 packet. At this point, the Initiator MAY
handshake or MAY restart the handshake by sending a new I1 containing abort the handshake or MAY restart the handshake by sending a new I1
a selection of DH Group IDs that is supported by the Responder. packet containing a selection of DH Group IDs that is supported by
the Responder.
4.1.7. HIP Downgrade Protection 4.1.7. HIP Downgrade Protection
In a downgrade attack, an attacker manipulates the packets of an In a downgrade attack, an attacker manipulates the packets of an
Initiator and/or a Responder to unnoticeably influence the result of Initiator and/or a Responder to unnoticeably influence the result of
the cryptographic negotiations in the BEX to its favor. As a result, the cryptographic negotiations in the BEX to its favor. As a result,
the victims select weaker cryptographic algorithms than they would the victims select weaker cryptographic algorithms than they would
have without the attacker's interference. Downgrade attacks can only otherwise have without the attacker's interference. Downgrade
be successful if these are not detected by the victims and the attacks can only be successful if they are remain un-detected by the
victims assume a secure communication channel. victims and the victims falsely assume a secure communication
channel.
In HIP, almost all packet parameters related to cryptographic In HIP, almost all packet parameters related to cryptographic
negotiations are covered by signatures. These parameters cannot be negotiations are covered by signatures. These parameters cannot be
directly manipulated in a downgrade attack without invalidating the directly manipulated in a downgrade attack without invalidating the
signature. However, signed packets can be subject to replay attacks. signature. However, signed packets can be subject to replay attacks.
In such a replay attack, the attacker could use an old BEX packet In such a replay attack, the attacker could use an old BEX packet
with an outdated selection of cryptographic algorithms and replay it with an outdated and weak selection of cryptographic algorithms and
instead of a more recent packet with a collection of stronger replay it instead of a more recent packet with a collection of
cryptographic algorithms. Signed packets that could be subject to stronger cryptographic algorithms. Signed packets that could be
this replay attack are the R1 and I2 packet. However, replayed R1 subject to this replay attack are the R1 and I2 packet. However,
and I2 packets cannot be used to successfully establish a HIP BEX replayed R1 and I2 packets cannot be used to successfully establish a
because these packets also contain the public DH values of the HIP BEX because these packets also contain the public DH values of
Initiator and the Responder. Old DH values from replayed packet will the Initiator and the Responder. Old DH values from replayed packets
lead to invalid keying material and mismatching shared secrets. lead to invalid keying material and mismatching shared secrets.
Because the attacker is unable to derive valid keying material from
the DH public keys in the R1 and cannot generate a valid HMAC and
signature for a replayed I2.
In contrast to the first version of HIP [RFC5201], this version In contrast to the first version of HIP [RFC5201], this version
begins the negotiation of the DH Groups already in the first BEX begins the negotiation of the DH Groups already in the first BEX
packet, the I1. The I1 is, by intention, not protected by a packet, the I1. The I1 packet is, by intention, not protected by a
signature to avoid CPU-intensive cryptographic operations for signature to avoid CPU-intensive cryptographic operations for
processing floods of I1s. Hence, the list of DH Group IDs in the I1 processing floods of I1 packets targeted at the Responder. Hence,
is vulnerable to forgery and manipulation. To thwart an unnoticed the list of DH Group IDs in the I1 packet is vulnerable to forgery
manipulation of the I1 packet, the Responder chooses the DH Group and manipulation. To thwart an unnoticed manipulation of the I1
deterministically and includes its own list of DH Group IDs in the packet, the Responder chooses the DH Group deterministically and
signed part of the R1 packet. The Initiator can detect an attempted includes its own list of DH Group IDs in the signed part of the R1
downgrade attack by comparing the list of DH Group IDs in the R1 packet. The Initiator can detect an attempted downgrade attack by
packet to its own preferences in the I1. If the choice of the DH comparing the list of DH Group IDs in the R1 packet to its own
Group in the R1 packet does not equal the best match of the two preferences in the I1 packet. If the choice of the DH Group in the
lists, the Initiator can conclude that its list in the I1 was altered R1 packet does not equal to the best match of the two lists (the
by an attacker. In this case, the Initiator can restart or abort the highest priority of the Responder that is present in the Initiator's
BEX. As mentioned before, the detection of the downgrade attack is DH list), the Initiator can conclude that its list in the I1 packet
sufficient to prevent it. was altered by an attacker. In this case, the Initiator can restart
or abort the BEX. As mentioned before, the detection of the
downgrade attack is sufficient to prevent it.
4.1.8. HIP Opportunistic Mode 4.1.8. HIP Opportunistic Mode
It is possible to initiate a HIP negotiation even if the Responder's It is possible to initiate a HIP BEX even if the Responder's HI (and
HI (and HIT) is unknown. In this case, the connection initializing HIT) is unknown. In this case, the initial I1 packet contains all
I1 packet contains NULL (all zeros) as the destination HIT. This zeros as the destination HIT. This kind of connection setup is
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 is not determined by the Suites. Since the Responder's HIT Suite is not determined by the
destination HIT of the I1 packet, the Responder can freely select a destination HIT of the I1 packet, the Responder can freely select a
HIT of any HIT Suite. The complete set of HIT Suites supported by HIT of any HIT Suite. The complete set of HIT Suites supported by
the Initiator is not known to the Responder. Therefore, the the Initiator is not known to the Responder. Therefore, the
Responder SHOULD use a Responder HIT of the same HIT Suite as the Responder SHOULD should select its HIT from the same HIT Suite as the
Initiator's HIT because this HIT Suite is obviously supported by the Initiator's HIT (indicated by the HIT suite information in the OGA
Initiator. If the Responder selects a different HIT that is not field of the Initiator's HIT) because this HIT Suite is obviously
supported by the Initiator, the Initiator MAY restart the BEX with an supported by the Initiator. If the Responder selects a different HIT
I1 packet with a source HIT that is contained in the list of the that is not supported by the Initiator, the Initiator MAY restart the
Responder's HIT Suites in the R1 packet. BEX with an I1 packet with a source HIT that is contained in the list
of the Responder's HIT Suites in the R1 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 a unverified HIT Suite List to determine a possible source that uses an unverified HIT Suite List from an R1 packet to determine
HIT from an R1 packet 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.
The Initiator MUST restart the BEX with a new I1 packet with a source The Initiator MUST restart the BEX with a new I1 packet for which the
HIT mentioned in the verifiable R1 if the two lists do not match to algorithm was mentioned in the verifiable R1 if the two lists do not
mitigate downgrade attacks. match. This procedure is necessary to mitigate downgrade attacks.
There are both security and API issues involved with the There are both security and API issues involved with the
opportunistic mode. opportunistic mode. These issues are described in the reminder of
this section.
Given that the Responder's HI is not known by the Initiator, there Given that the Responder's HI is not known by the Initiator, there
must be suitable API calls that allow the Initiator to request, must be suitable API calls that allow the Initiator to request,
directly or indirectly, that the underlying kernel initiate the HIP directly or indirectly, that the underlying system initiates the HIP
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, it could once the R2 packet has been received and verified. Hence, the
be communicated to the application via new API mechanisms. However, Responder's HIT could be communicated to the application via new API
with a backwards-compatible API the application sees only the mechanisms. However, with a backwards-compatible API the application
locators used for the initial contact. Depending on the desired sees only the locators used for the initial contact. Depending on
semantics of the API, this can raise the following issues: the desired semantics of the API, this can raise the following
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 session still appears to be
between specific locators. The locator update is still secure, between two specific locators. However, the locator update is
however, and the session is still between the same nodes. still secure and the session is still between the same nodes.
o Different sessions between the same locators may result in o Different sessions 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 another session. This remembers which identifier the peer had in an earlier session.
is possible when the peer's locator has changed for legitimate This is possible when the peer's locator has changed for
reasons or when an attacker pretends to be a node that has the legitimate reasons or when an attacker pretends to be a node that
peer's locator. Therefore, when using opportunistic mode, HIP has the peer's locator. Therefore, when using opportunistic mode,
MUST NOT place any expectation that the peer's HI returned in the HIP implementations MUST NOT place any expectation that the peer's
R1 message matches any HI previously seen from that address. HI returned in the R1 message matches any HI previously seen from
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 a session, this may even happen
within the same session. For instance, an implementation may not within the same session. For instance, an implementation may not
know when HIP state can be purged for UDP-based applications. know when HIP state can be purged for UDP-based applications.
o As with all HIP exchanges, the handling of locator-based or o As with all HIP exchanges, the handling of locator-based or
interface-based policy is unclear for opportunistic mode HIP. An interface-based policy is unclear for HIP in opportunistic mode.
application may make a connection to a specific locator because An application may create a connection to a specific locator
the application has knowledge of the security properties along the because the application has knowledge of the security properties
network to that locator. If one of the nodes moves and the along the network to that locator. If one of the nodes moves and
locators are updated, these security properties may not be the locators are updated, these security properties may not be
maintained. Depending on the security policy of the application, maintained. Depending on the security policy of the application,
this may be a problem. This is an area of ongoing study. As an 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 example, there is work to create an API that applications can use
to specify their security requirements in a similar context to specify their security requirements in a similar context
[btns-c-api]. [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 any HI, not just the one given in the I1 packet. a replay that uses an arbitrary HI, not just the one given in the I1
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 session towards the Responder. For
this to be possible, the Initiator must employ opportunistic mode, this to be possible, the Initiator must employ opportunistic mode,
and the Responder must be configured to accept a connection from any and the Responder must be configured to accept a connection from any
HIP-enabled node. 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 properties are characteristic also of communications in the These security properties are characteristic also of communications
current Internet. A client contacting a server without employing in the current Internet. A client contacting a server without
end-to-end security may find itself talking to the server via a man- employing end-to-end security may find itself talking to the server
in-the-middle, assuming again that the server is willing to talk to via a man-in-the-middle, assuming again that the server is willing to
anyone. talk to anyone.
If end-to-end security is in place, then the worst that can happen in If end-to-end security is in place, then the worst that can happen in
both the opportunistic HIP and normal IP cases is denial-of-service; both the opportunistic HIP and non-HIP (normal IP) cases is denial-
an entity on the path can disrupt communications, but will be unable of-service; an entity on the path can disrupt communications, but
to insert itself as a man-in-the-middle. will be unable to successfully insert itself as a man-in-the-middle.
However, once the opportunistic exchange has successfully completed, However, once the opportunistic exchange has successfully completed,
HIP provides integrity protection and confidentiality for the HIP provides confidentiality and integrity protection for the
communications, and can securely change the locators of the communications, and can securely change the locators of the
endpoints. endpoints.
As a result, it is believed that the HIP opportunistic mode is at As a result, it is believed that the HIP opportunistic mode is at
least as secure as current IP. least as secure as current IP.
4.2. Updating a HIP Association 4.2. Updating a HIP Association
A HIP association between two hosts may need to be updated over time. A HIP association between two hosts may need to be updated over time.
Examples include the need to rekey expiring user data security Examples include the need to rekey expiring user data security
skipping to change at page 23, line 47 skipping to change at page 24, line 39
HIP error processing behavior depends on whether or not there exists HIP error processing behavior depends on whether or not there exists
an active HIP association. In general, if a HIP association exists an active HIP association. In general, if a HIP association exists
between the sender and receiver of a packet causing an error between the sender and receiver of a packet causing an error
condition, the receiver SHOULD respond with a NOTIFY packet. On the condition, the receiver SHOULD respond with a NOTIFY packet. On the
other hand, if there are no existing HIP associations between the other hand, if there are no existing HIP associations between the
sender and receiver, or the receiver cannot reasonably determine the sender and receiver, or the receiver cannot reasonably determine the
identity of the sender, the receiver MAY respond with a suitable ICMP identity of the sender, the receiver MAY respond with a suitable ICMP
message; see Section 5.4 for more details. message; see Section 5.4 for more details.
The HIP protocol and state machine is designed to recover from one of The HIP protocol and state machine are designed to recover from one
the parties crashing and losing its state. The following scenarios of the parties crashing and losing its state. The following
describe the main use cases covered by the design. scenarios describe the main use cases covered by the design.
No prior state between the two systems. No prior state between the two systems.
The system with data to send is the Initiator. The process The system with data to send is the Initiator. The process
follows the standard four-packet base exchange, establishing follows the standard four-packet base exchange, establishing
the HIP association. the HIP association.
The system with data to send has no state with the receiver, but The system with data to send has no state with the receiver, but
the receiver has a residual HIP association. the receiver has a residual HIP association.
The system with data to send is the Initiator. The Initiator The system with data to send is the Initiator. The Initiator
acts as in no prior state, sending I1 and getting R1. When the acts as in no prior state, sendin an I1 packet and receiving an
Responder receives a valid I2, the old association is R1 packet. When the Responder receives a valid I2 packet, the
'discovered' and deleted, and the new association is old association is 'discovered' and deleted, and the new
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 Optionally, the receiving host MAY send an ICMP packet, with
the type Parameter Problem, to inform the sender that the HIP the type 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 negotiation. 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.
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.
The state machine is presented in a single system view, representing The state machine is symmetric and is presented in a single system
either an Initiator or a Responder. There is not a complete overlap view, representing either an Initiator or a Responder. The state
of processing logic here and in the packet definitions. Both are machine is not a full representation of the processing logic.
needed to completely implement HIP. Additional processing rules are presented in the packet definitions.
Hence, both are needed to completely implement HIP.
This document extends the state machine defined in [RFC5201] and This document extends the state machine as defined in [RFC5201] and
introduces a restart option to allow for the negotiation of introduces a restart option to allow for the negotiation of
cryptographic algorithms. The only change to the previous state cryptographic algorithms. The extension to the previous state
machine is a transition from state I1-SENT to I1-SENT - the restart machine in [RFC5201] is a transition from state I1-SENT to I1-SENT -
option. An Initiator is required to restart the HIP exchange if the the restart option. An Initiator is required to restart the HIP
Responder does not support the HIT Suite of the Initiator. In this exchange if the Responder does not support the HIT Suite of the
case, the Initiator restarts the HIP exchange by sending a new I1 Initiator. In this case, the Initiator restarts the HIP exchange by
packet with a source HIT supported by the Responder. sending a new I1 packet with a source HIT supported by the Responder.
Implementors must understand that the state machine, as described Implementors must understand that the state machine, as described
here, is informational. Specific implementations are free to here, is informational. Specific implementations are free to
implement the actual functions differently. Section 6 describes the implement the actual processing logic differently. Section 6
packet processing rules in more detail. This state machine focuses describes the packet processing rules in more detail. This state
on the HIP I1, R1, I2, and R2 packets only. Other states may be machine focuses on the HIP I1, R1, I2, and R2 packets only. New
introduced by mechanisms in other specifications (such as mobility states may be introduced by mechanisms in other specifications (such
and multihoming). as mobility and multihoming).
4.4.1. Timespan Definitions 4.4.1. Timespan Definitions
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 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 TCP segment is
expected to spend in the network. expected to spend in the network.
Exchange Complete (EC): Time that the host spends at the R2-SENT Exchange Complete (EC): Time that the host spends at the R2-SENT
before it moves to ESTABLISHED state. The time is n * I2 before it moves to ESTABLISHED state. The time is n * I2
retransmission timeout, where n is about I2_RETRIES_MAX. retransmission timeout, where n is about I2_RETRIES_MAX.
4.4.2. HIP States 4.4.2. HIP States
skipping to change at page 26, line 23 skipping to change at page 27, line 23
| 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 | | Receive user data | Optionally send ICMP as defined in |
| for unknown HIP | Section 5.4 and stay at UNASSOCIATED | | for an unknown HIP | Section 5.4 and stay at UNASSOCIATED |
| association | | | association | |
| | | | | |
| Receive CLOSE | Optionally send ICMP Parameter Problem and | | Receive CLOSE | Optionally send ICMP Parameter Problem and |
| | stay at UNASSOCIATED | | | 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
skipping to change at page 27, line 20 skipping to change at page 28, line 20
| Receive I1 | If the local HIT is smaller than the peer | | Receive I1 | If the local HIT is smaller than the peer |
| | HIT, drop I1 and stay at I1-SENT | | | HIT, drop I1 and stay at I1-SENT |
| | | | | |
| | If the local HIT is greater than the peer | | | If the local HIT is greater than the peer |
| | HIT, send R1 and stay at I1_SENT | | | HIT, send R1 and stay at I1_SENT |
| | | | | |
| 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 I1-SENT | | | If fail, stay at I1-SENT |
| | | | | |
| Receive R1, process | If HIT Suite of own HIT is not supported by | | Receive R1, process | If the HIT Suite of the local HIT is not |
| | the peer, select supported own HIT, send I1 | | | supported by the peer, select supported |
| | 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 | If counter is less than I1_RETRIES_MAX, | | Timeout | Increment timeout counter |
| timeout counter | send I1 and stay at I1-SENT | | | |
| | If counter is less than I1_RETRIES_MAX, |
| | 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 HIP Table 3: I1-SENT - Initiating HIP
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 cycle at I2-SENT | | Receive R1, process | If successful, send I2 and stay at I2-SENT |
| | | | | |
| | If fail, stay at I2-SENT | | | If fail, stay at I2-SENT |
| | | | | |
| Receive I2, process | If successful and local HIT is smaller than | | Receive I2, process | If successful and local HIT is smaller than |
| | the peer HIT, drop I2 and stay at I2-SENT | | | the peer HIT, drop I2 and stay at I2-SENT |
| | | | | |
| | If successful and local HIT is greater than | | | If successful and local HIT is greater than |
| | the peer HIT, send R2 and go to R2-SENT | | | the peer HIT, send R2 and go to R2-SENT |
| | | | | |
| | If fail, stay at I2-SENT | | | If fail, stay at I2-SENT |
skipping to change at page 28, line 35 skipping to change at page 29, 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 | If counter is less than I2_RETRIES_MAX, | | Timeout | Increment timeout counter |
| timeout counter | send I2 and stay at I2-SENT | | | |
| | If counter is less than I2_RETRIES_MAX, |
| | 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 HIP Table 4: I2-SENT - Waiting to finish HIP
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 cycle 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 | | Receive data or | Move to ESTABLISHED |
| UPDATE | | | UPDATE | |
| | | | | |
skipping to change at page 30, line 12 skipping to change at page 31, line 12
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 |
| | | | | |
| Receive I2, process | If successful, send R2, drop old HIP | | Receive I2 | Process with puzzle and possible Opaque |
| with puzzle and | association, establish a new HIP | | | data verification |
| possible Opaque | association, go to R2-SENT | | | |
| data verification | | | | If successful, send R2, drop old HIP |
| | association, establish a new HIP |
| | association and go to R2-SENT |
| | | | | |
| | If fail, stay at ESTABLISHED | | | If fail, stay at ESTABLISHED |
| | | | | |
| Receive R1 | Drop and stay at ESTABLISHED | | Receive R1 | Drop and stay at ESTABLISHED |
| | | | | |
| Receive R2 | Drop and stay at ESTABLISHED | | Receive R2 | Drop and stay at ESTABLISHED |
| | | | | |
| Receive user data | Process and stay at ESTABLISHED | | Receive user data | Process and stay at ESTABLISHED |
| for HIP association | | | for HIP association | |
| | | | | |
skipping to change at page 32, line 47 skipping to change at page 33, line 47
| Timeout (UAL+2MSL) | Discard state, and go to UNASSOCIATED | | 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 |
| time | state. | | time | state. |
+-------------------------+-----------------------------------------+ +-------------------------+-----------------------------------------+
Table 9: E-FAILED - HIP failed to establish association with peer Table 9: E-FAILED - HIP failed to establish association with peer
4.4.4. Simplified HIP State Diagram 4.4.4. Simplified HIP State Diagram
The following diagram shows the major state transitions. Transitions The following diagram shows the major state transitions. Transitions
based on received packets implicitly assume that the packets are based on received packets implicitly assume that the packets are
successfully authenticated or processed. successfully authenticated or processed.
skipping to change at page 35, line 20 skipping to change at page 36, line 20
through sockets bound to HITs, the IPv6 pseudo-header format through sockets bound to HITs, the IPv6 pseudo-header format
[RFC2460] MUST be used, even if the actual addresses on the packet [RFC2460] MUST be used, even if the actual addresses on the packet
are IPv4 addresses. Additionally, the HITs MUST be used in the place are IPv4 addresses. Additionally, the HITs MUST be used in the place
of the IPv6 addresses in the IPv6 pseudo-header. Note that the of the IPv6 addresses in the IPv6 pseudo-header. Note that the
pseudo-header for actual HIP payloads is computed differently; see pseudo-header for actual HIP payloads is computed differently; see
Section 5.1.1. Section 5.1.1.
4.5.2. Sending Data on HIP Packets 4.5.2. Sending Data on HIP Packets
A future version of this document may define how to include user data A future version of this document may define how to include user data
on various HIP packets. However, currently the HIP header is a in various HIP packets. However, currently the HIP header is a
terminal header, and not followed by any other headers. terminal header, and not followed by any other headers.
4.5.3. Transport Formats 4.5.3. Transport Formats
The actual data transmission format, used for user data after the HIP The actual data transmission format, used for user data after the HIP
base exchange, is not defined in this document. Such transport base exchange, is not defined in this document. Such transport
formats and methods are described in separate specifications. All formats and methods are described in separate specifications. All
HIP implementations MUST implement, at minimum, the ESP transport HIP implementations MUST implement, at minimum, the ESP transport
format for HIP [RFC5202]. format for HIP [I-D.ietf-hip-rfc5202-bis].
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
exchange has completed, the Initiator can create a new payload exchange has completed, the Initiator can create a new payload
association and start sending data. The peer does not reset its association and start sending data. The peer does not reset its
state until it receives a valid I2 HIP packet. state until it receives a valid I2 packet.
If a system receives a user data packet that cannot be matched to any If a system receives a user data packet that cannot be matched to any
existing HIP association, it is possible that it has lost the state existing HIP association, it is possible that it has lost the state
and its peer has not. It MAY send an ICMP packet with the Parameter and its peer has not. It MAY send an ICMP packet with the Parameter
Problem type, and with the pointer pointing to the referred HIP- Problem type, and with the pointer pointing to the referred HIP-
related association information. Reacting to such traffic depends on related association information. Reacting to such traffic depends on
the implementation and the environment where the implementation is the implementation and the environment where the implementation is
used. used.
If the host, that apparently has lost its state, decides to restart If the host, that apparently has lost its state, decides to restart
skipping to change at page 37, line 18 skipping to change at page 38, line 18
parameters in 8-byte units, excluding the first 8 bytes. Since all parameters in 8-byte units, excluding the first 8 bytes. Since all
HIP headers MUST contain the sender's and receiver's HIT fields, the HIP headers MUST contain the sender's and receiver's HIT fields, the
minimum value for this field is 4, and conversely, the maximum length minimum value for this field is 4, and conversely, the maximum length
of the HIP Parameters field is (255*8)-32 = 2008 bytes. Note: this of the HIP Parameters field is (255*8)-32 = 2008 bytes. Note: this
sets an additional limit for sizes of parameters included in the sets an additional limit for sizes of parameters included in the
Parameters field, independent of the individual parameter maximum Parameters field, independent of the individual parameter maximum
lengths. lengths.
The Packet Type indicates the HIP packet type. The individual packet The Packet Type indicates the HIP packet type. The individual packet
types are defined in the relevant sections. If a HIP host receives a types are defined in the relevant sections. If a HIP host receives a
HIP packet that contains an unknown packet type, it MUST drop the HIP packet that contains an unrecognized packet type, it MUST drop
packet. the packet.
The HIP Version is four bits. The current version is 2. The version The HIP Version is four bits. The current version is 2. The version
number is expected to be incremented only if there are incompatible number is expected to be incremented only if there are incompatible
changes to the protocol. Most extensions can be handled by defining changes to the protocol. Most extensions can be handled by defining
new packet types, new parameter types, or new controls. new packet types, new parameter types, or new controls.
The following three bits are reserved for future use. They MUST be The following three bits are reserved for future use. They MUST be
zero when sent, and they SHOULD be ignored when handling a received zero when sent, and they SHOULD be ignored when handling a received
packet. packet.
skipping to change at page 37, line 47 skipping to change at page 38, line 47
that the forthcoming SHIM6 protocol happens to be compatible with that the forthcoming SHIM6 protocol happens to be compatible with
this specification, an implementation that implements both this this specification, an implementation that implements both this
specification and the SHIM6 protocol may need to check these bits in specification and the SHIM6 protocol may need to check these bits in
order to determine how to handle the packet. order to determine how to handle the packet.
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 4) in the Next Header field. The length field is
in bytes and can be calculated from the HIP header length field: (HIP in bytes and can be calculated from the HIP header length field: (HIP
Header Length + 1) * 8. 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
skipping to change at page 38, line 31 skipping to change at page 39, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | |A| | | | | | | | | | | | | | | | |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A - Anonymous: If this is set, the sender's HI in this packet is A - Anonymous: If this is set, the sender's HI in this packet is
anonymous, i.e., one not listed in a directory. Anonymous HIs anonymous, i.e., one not listed in a directory. Anonymous HIs
SHOULD NOT be stored. This control is set in packets R1 and/or SHOULD NOT be stored. This control is set in packets R1 and/or
I2. The peer receiving an anonymous HI may choose to refuse it. I2. The peer receiving an anonymous HI may choose to refuse it.
The rest of the fields are reserved for future use and MUST be set to The rest of the fields are reserved for future use and MUST be set to
zero on sent packets and ignored on received packets. zero in sent packets and ignored in received packets.
5.1.3. HIP Fragmentation Support 5.1.3. HIP Fragmentation Support
A HIP implementation must support IP fragmentation/reassembly. A HIP implementation must support IP fragmentation/reassembly.
Fragment reassembly MUST be implemented in both IPv4 and IPv6, but Fragment reassembly MUST be implemented in both IPv4 and IPv6, but
fragment generation is REQUIRED to be implemented in IPv4 (IPv4 fragment generation is REQUIRED to be implemented in IPv4 (IPv4
stacks and networks will usually do this by default) and RECOMMENDED stacks and networks will usually do this by default) and RECOMMENDED
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
skipping to change at page 39, line 21 skipping to change at page 40, line 21
[KAU03], it is strongly recommended that the separate document [KAU03], it is strongly recommended that the separate document
specifying the certificate usage in the HIP Base Exchange defines the specifying the certificate usage in the HIP Base Exchange defines the
usage of "Hash and URL" formats rather than including certificates in usage of "Hash and URL" formats rather than including certificates in
exchanges. With this, most problems related to DoS attacks with exchanges. With this, most problems related to DoS attacks with
fragmentation can be avoided. fragmentation can be avoided.
5.2. HIP Parameters 5.2. HIP Parameters
The HIP Parameters are used to carry the public key associated with The HIP Parameters are used to carry the public key associated with
the sender's HIT, together with related security and other the sender's HIT, together with related security and other
information. They consist of ordered parameters, encoded in TLV information. They consist of parameters, ordered according to their
format. numeric type number and encoded in TLV format.
The following parameter types are currently defined. The following parameter types are currently defined.
+------------------------+-------+----------+-----------------------+ +------------------------+-------+----------+-----------------------+
| TLV | Type | Length | Data | | TLV | Type | Length | Data |
+------------------------+-------+----------+-----------------------+ +------------------------+-------+----------+-----------------------+
| R1_COUNTER | 128 | 12 | System Boot Counter | | R1_COUNTER | 128 | 12 | System Boot Counter |
| | | | | | | | | |
| PUZZLE | 257 | 12 | K and Random #I | | PUZZLE | 257 | 12 | K and Random #I |
| | | | | | | | | |
skipping to change at page 40, line 41 skipping to change at page 41, line 41
| | | | Domain FQDN (Name) or | | | | | Domain FQDN (Name) or |
| | | | Network Access | | | | | Network Access |
| | | | Identifier (NAI) | | | | | Identifier (NAI) |
| | | | | | | | | |
| HIT_SUITE_LIST | 715 | variable | Ordered list of the | | HIT_SUITE_LIST | 715 | variable | Ordered list of the |
| | | | HIT suites supported | | | | | HIT suites supported |
| | | | by the Responder | | | | | by the Responder |
| | | | | | | | | |
| CERT | 768 | variable | HI Certificate; used | | CERT | 768 | variable | HI Certificate; used |
| | | | to transfer | | | | | to transfer |
| | | | certificates. Usage | | | | | certificates. Usage |
| | | | is currently not | | | | | is currently not |
| | | | defined, but it will | | | | | defined, but it will |
| | | | be specified in a | | | | | be specified in a |
| | | | separate document | | | | | separate document |
| | | | once needed. | | | | | once needed. |
| | | | | | | | | |
| NOTIFICATION | 832 | variable | Informational data | | NOTIFICATION | 832 | variable | Informational data |
| | | | | | | | | |
| ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be |
| | | | echoed back; under | | | | | echoed back; under |
skipping to change at page 41, line 19 skipping to change at page 42, line 19
| | | | by a host | | | | | by a host |
| | | | | | | | | |
| 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. Compared | | | | | from KEYMAT. |
| | | | to HIP_MAC, the | | | | | Compared to HIP_MAC, |
| | | | HOST_ID parameter is | | | | | the HOST_ID parameter |
| | | | included in HIP_MAC_2 | | | | | is included in |
| | | | HIP_MAC_2 |
| | | | calculation. | | | | | calculation. |
| | | | | | | | | |
| HIP_SIGNATURE_2 | 61633 | variable | Signature of the R1 | | HIP_SIGNATURE_2 | 61633 | variable | Signature of the R1 |
| | | | packet | | | | | packet |
| | | | | | | | | |
| HIP_SIGNATURE | 61697 | variable | Signature of the | | HIP_SIGNATURE | 61697 | variable | Signature of the |
| | | | packet | | | | | packet |
| | | | | | | | | |
| ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be | | ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be |
| | | | echoed back; after | | | | | echoed back; after |
| | | | signature | | | | | signature |
| | | | | | | | | |
| ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed | | ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed |
| | | | back; after signature | | | | | back; after signature |
+------------------------+-------+----------+-----------------------+ +------------------------+-------+----------+-----------------------+
Because 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 - 8191 | Signed parameters allocated through specification | | 2048 - 4095 | Parameters related to HIP transport types |
| | |
| 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 - 62463 | Signatures and (signed) MACs | | 61440 - 62463 | 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 |
| | | | | |
| 64512 - 65023 | Parameters that are neither signed nor MACed | | 64512 - 65023 | Parameters that are neither signed nor MACed |
skipping to change at page 43, line 4 skipping to change at page 44, line 7
fields in the packet, except for type values from 2048 to 4095 which fields in the packet, except for type values from 2048 to 4095 which
are reserved for new transport forms. The parameters MUST be are reserved for new transport forms. The parameters MUST be
included in the packet such that their types form an increasing included in the packet such that their types form an increasing
order. If the parameter can exist multiple times in the packet, the order. If the parameter can exist multiple times in the packet, the
type value may be the same in consecutive parameters. If the order type value may be the same in consecutive parameters. If the order
does not follow this rule, the packet is considered to be malformed does not follow this rule, the packet is considered to be malformed
and it MUST be discarded. and it MUST be discarded.
Parameters using type values from 2048 up to 4095 are transport Parameters using type values from 2048 up to 4095 are transport
formats. Currently, one transport format is defined: the ESP formats. Currently, one transport format is defined: the ESP
transport format [RFC5202]. The order of these parameters does not transport format [I-D.ietf-hip-rfc5202-bis]. The order of these
follow the order of their type value, but they are put in the packet parameters does not follow the order of their type value, but they
in order of preference. The first of the transport formats it the are put in the packet in order of preference. The first of the
most preferred, and so on. transport formats it the most preferred, and so on.
All of the TLV parameters have a length (including Type and Length All of the TLV parameters have a length (including Type and Length
fields), which is a multiple of 8 bytes. When needed, padding MUST fields), which is a multiple of 8 bytes. When needed, padding MUST
be added to the end of the parameter so that the total length becomes be added to the end of the parameter so that the total length is a
a multiple of 8 bytes. This rule ensures proper alignment of data. multiple of 8 bytes. This rule ensures proper alignment of data.
Any added padding bytes MUST be zeroed by the sender, and their Any added padding bytes MUST be zeroed by the sender, and their
values SHOULD NOT be checked by the receiver. values SHOULD NOT be checked by the receiver.
Consequently, the Length field indicates the length of the Contents Consequently, the Length field indicates the length of the Contents
field (in bytes). The total length of the TLV parameter (including field (in bytes). The total length of the TLV parameter (including
Type, Length, Contents, and Padding) is related to the Length field Type, Length, Contents, and Padding) is related to the Length field
according to the following formula: according to the following formula:
Total Length = 11 + Length - (Length + 3) % 8; Total Length = 11 + Length - (Length + 3) % 8;
skipping to change at page 43, line 48 skipping to change at page 44, line 51
C Critical. One if this parameter is critical, and C Critical. One if this parameter is critical, and
MUST be recognized by the recipient, zero otherwise. MUST be recognized by the recipient, zero otherwise.
The C bit is considered to be a part of the Type The C bit is considered to be a part of the Type
field. Consequently, critical parameters are always field. Consequently, critical parameters are always
odd and non-critical ones have an even value. odd and non-critical ones have an even value.
Length Length of the Contents, in bytes excluding Type, Length Length of the Contents, in bytes excluding Type,
Length, and Padding. Length, and Padding.
Contents Parameter specific, defined by Type Contents Parameter specific, defined by Type
Padding Padding, 0-7 bytes, added if needed Padding Padding, 0-7 bytes, added if needed
Critical parameters MUST be recognized by the recipient. If a Critical parameters (indicated by the odd type number) MUST be
recipient encounters a critical parameter that it does not recognize, recognized by the recipient. If a recipient encounters a critical
it MUST NOT process the packet any further. It MAY send an ICMP or parameter that it does not recognize, it MUST NOT process the packet
NOTIFY, as defined in Section 4.3. any further. It MAY send an ICMP or NOTIFY, as defined in
Section 4.3.
Non-critical parameters MAY be safely ignored. If a recipient Non-critical parameters MAY be safely ignored. If a recipient
encounters a non-critical parameter that it does not recognize, it encounters a non-critical parameter that it does not recognize, it
SHOULD proceed as if the parameter was not present in the received SHOULD proceed as if the parameter was not present in the received
packet. packet.
5.2.2. Defining New Parameters 5.2.2. Defining New Parameters
Future specifications may define new parameters as needed. When Future specifications may define new parameters as needed. When
defining new parameters, care must be taken to ensure that the defining new parameters, care must be taken to ensure that the
parameter type values are appropriate and leave suitable space for parameter type values are appropriate and leave suitable space for
other future extensions. One must remember that the parameters MUST other future extensions. One must remember that the parameters MUST
always be arranged in increasing order by Type code, thereby limiting always be arranged in numerically increasing order by Type code,
the order of parameters (see Section 5.2.1). thereby limiting the order of parameters (see Section 5.2.1).
The following rules must be followed when defining new parameters. The following rules must be followed when defining new parameters.
1. The low-order bit C of the Type code is used to distinguish 1. The low-order bit C of the Type code is used to distinguish
between critical and non-critical parameters. Hence, even between critical and non-critical parameters. Hence, even
parameter type numbers indicate non-critical parameters while odd parameter type numbers indicate non-critical parameters while odd
parameter type numbers indicate critical parameters. parameter type numbers indicate critical parameters.
2. A new parameter may be critical only if an old recipient ignoring 2. A new parameter may be critical only if an old implementation
it would cause security problems. In general, new parameters that ignored it would cause security problems. In general, new
SHOULD be defined as non-critical, and expect a reply from the parameters SHOULD be defined as non-critical, and expect a reply
recipient. from the recipient.
3. If a system implements a new critical parameter, it MUST provide 3. If a system implements a new critical parameter, it MUST provide
the ability to set the associated feature off, such that the the ability to set the associated feature off, such that the
critical parameter is not sent at all. The configuration option critical parameter is not sent at all. The configuration option
must be well documented. Implementations operating in a mode MUST be well documented. Implementations operating in a mode
adhering to this specification MUST disable the sending of new adhering to this specification MUST disable the sending of new
critical parameters. In other words, the management interface critical parameters. In other words, the management interface
MUST allow vanilla standards-only mode as a default configuration MUST allow vanilla standards-only mode as a default configuration
setting, and MAY allow new critical payloads to be configured on setting, and MAY allow new critical payloads to be configured on
(and off). (and off).
4. See Section 10 for allocation rules regarding Type codes. 4. See Section 10 for allocation rules regarding Type codes.
5.2.3. R1_COUNTER 5.2.3. R1_COUNTER
skipping to change at page 45, line 33 skipping to change at page 46, line 33
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 is supposed to increment this counter puzzles. The sender is supposed to increment this counter
periodically. It is RECOMMENDED that the counter value is periodically. It is RECOMMENDED that the counter value is
incremented at least as often as old PUZZLE values are deprecated so incremented at least as often as old PUZZLE values are deprecated so
that SOLUTIONs to them are no longer accepted. that SOLUTIONs to them are no longer accepted.
The R1_COUNTER parameter is optional. It SHOULD be included in the The R1_COUNTER parameter is optional. It SHOULD be included in the
R1 (in which case, it is covered by the signature), and if present in R1 (in which case, it is covered by the signature), and if present in
the R1, it MAY be echoed (including the Reserved field verbatim) by the R1, it MAY be echoed (including the Reserved field verbatim) by
the Initiator in the I2. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 46, line 29 skipping to change at page 47, line 29
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), K 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. 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
puzzle random integer #I. The Puzzle Lifetime indicates the time random integer #I. The Puzzle Lifetime indicates the time during
during which the puzzle solution is valid, and sets a time limit that which the puzzle solution is valid, and sets a time limit that should
should not be exceeded by the Initiator while it attempts to solve not be exceeded by the Initiator while it attempts to solve the
the puzzle. The lifetime is indicated as a power of 2 using the puzzle. The lifetime is indicated as a power of 2 using the formula
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, allowing the ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED, allowing the
Responder to use the included information as a part of its puzzle Responder to use the included information as a part of its puzzle
processing. 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
skipping to change at page 48, line 37 skipping to change at page 49, line 37
The following Group IDs have been defined: The following Group IDs have been defined:
Group Value Group Value
Reserved 0 Reserved 0
DEPRECATED 1 DEPRECATED 1
DEPRECATED 2 DEPRECATED 2
1536-bit MODP group 3 [RFC3526] 1536-bit MODP group 3 [RFC3526]
3072-bit MODP group 4 [RFC3526] 3072-bit MODP group 4 [RFC3526]
DEPRECATED 5 DEPRECATED 5
DEPRECATED 6 DEPRECATED 6
160-bit rnd. ECP grp 7 [App. D,draft-mcgrew-fundamental-ecc-02.txt] NIST P-256 7 [RFC4753]
256-bit rnd. ECP grp 8 [RFC4753,draft-mcgrew-fundamental-ecc-02.txt] NIST P-384 8 [RFC4753]
384-bit rnd. ECP grp 9 [RFC4753,draft-mcgrew-fundamental-ecc-02.txt] NIST P-521 9 [RFC4753]
521-bit rnd. ECP grp 10[RFC4753,draft-mcgrew-fundamental-ecc-02.txt] SECP160R1 10 [SECG]
The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH
groups 8 - 10 are defined in [RFC4753] and [fundamental-ecc]. ECDH groups 8 - 10 are defined in [RFC4753] and
group 7 is covered in Appendix D. [I-D.mcgrew-fundamental-ecc]. ECDH group 7 is covered in Appendix D.
A HIP implementation MUST implement Group ID 3. The 160-bit ECP A HIP implementation MUST implement Group ID 3. The 160-bit ECP
group can be used when lower security is enough (e.g., web surfing) group can be used when lower security is enough (e.g., web surfing)
and when the equipment is not powerful enough (e.g., some PDAs). and when the equipment is not powerful enough (e.g., some PDAs).
Implementations SHOULD implement Group IDs 4 and 8. Implementations SHOULD implement Group IDs 4 and 8.
To avoid unnecessary failures during the base exchange, the rest of To avoid unnecessary failures during the base exchange, the rest of
the groups SHOULD be implemented in hosts where resources are the groups SHOULD be implemented in hosts where resources are
adequate. adequate.
skipping to change at page 49, line 47 skipping to change at page 50, line 46
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 transforms 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. That Initiator MUST choose only one of the corresponding Cipher IDs. This
Cipher ID will be used for generating the ENCRYPTED parameter. Cipher ID will be used for generating the ENCRYPTED parameter.
Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION is included Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION is included
for testing purposes. NULL-ENCRYPTION SHOULD NOT be configurable via for testing purposes. NULL-ENCRYPTION SHOULD NOT be configurable via
the UI. the UI.
5.2.8. HOST_ID 5.2.8. HOST_ID
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HI Length |DI-type| DI Length | | HI Length |DI-type| DI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Identity / | Algorithm | Host Identity /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Domain Identifier / / | Domain Identifier /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding | / | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 705 Type 705
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
Padding Padding
HI Length length of the Host Identity in octets HI Length length of the Host Identity in octets
DI-type type of the following Domain Identifier field DI-type type of the following Domain Identifier field
Algorithm index to the employed algorithm
DI Length length of the FQDN or NAI in octets DI Length length of the FQDN or NAI in octets
Host Identity actual Host Identity Host Identity actual Host Identity
Domain Identifier the identifier of the sender Domain Identifier the identifier of the sender
The Host Identity is represented in the DNSKEY format for RSA and The Host Identity is derived from the DNSKEY format for RSA and DSA.
DSA. For these, the Public Key field from RFC 4034 [RFC4034] is For these, the Public Key field of the RDATA part from RFC 4034
used. For ECC Host Identities this field is defined here directly. [RFC4034] is used. For ECC we distinguish two different profiles:
ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and
defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with
low computational capabilities and uses shorter curves from SECG
[SECG].
Algorithms Values Algorithm
profiles Values
RESERVED 0 RESERVED 0
DSA 3 [RFC2536] (RECOMMENDED) DSA 3 [RFC2536] (RECOMMENDED)
RSA 5 [RFC3110] (REQUIRED) RSA 5 [RFC3110] (REQUIRED)
ECDSA 7 [fundamental-ecc] (RECOMMENDED) ECDSA 7 [RFC4754] (RECOMMENDED)
ECDSA_LOW 9 [SECG] (RECOMMENDED)
For ECDSA the Host Identity is represented by the following fields: For ECDSA and ECDSA_LOW Host Identities is represented by the
following fields:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECC Curve | | | ECC Curve | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key / / Public Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ECC Curve Curve label ECC Curve Curve label
Public Key Represented in Octet-string format [fundamental-ecc] Public Key Represented in Octet-string format
[I-D.mcgrew-fundamental-ecc]
Required ECC Curve values are: For hosts that implement ECDSA as algorithm the following ECC curves
are required:
Curve Values Algorithm Curve Values
RESERVED 0 ECDSA RESERVED 0
NIST-ECDSA-256 1 [RFC4754]
NIST-ECDSA-384 2 [RFC4754] ECDSA NIST P-256 1 [RFC4754]
brainpoolP160r1 3 [RFC5639] ECDSA NIST P-384 2 [RFC4754]
For hosts that implement the EDSA_LOW algorithm profile, the
following curve is required:
Algorithm Curve Values
ECDSA_LOW RESERVED 0
ECDSA_LOW SECP160R1 1 [SECG]
The following DI-types have been defined: The following DI-types have been defined:
Type Value Type Value
none included 0 none included 0
FQDN 1 FQDN 1
NAI 2 NAI 2
FQDN Fully Qualified Domain Name, in binary format. FQDN Fully Qualified Domain Name, in binary format.
NAI Network Access Identifier NAI Network Access Identifier
The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1. The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1.
The format for NAI is defined in [RFC4282] The format for the NAI is defined in [RFC4282]
If there is no Domain Identifier, i.e., the DI-type field is zero, If there is no Domain Identifier, i.e., the DI-type field is zero,
the DI Length field is set to zero as well. the DI Length field is set to zero as well.
5.2.9. HIT_SUITE_LIST 5.2.9. HIT_SUITE_LIST
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 52, line 22 skipping to change at page 53, line 22
| 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 defines a HIT Suite ID supported by the host.
The list of IDs is ordered by preference of the The list of IDs is ordered by preference of the
host. Each HIT Suite ID is one octet long. The four host. Each HIT Suite ID is one octet long. The four
higher-order bits correspond to the HIT Suite ID in higher-order bits of the ID field correspond to the
the ORCHID OGA field. The four lower-order bits are HIT Suite ID in the ORCHID OGA field. The four
set to 0. lower-order bits are reserved and set to 0. The four
lower-order bits are ignored.
The ID field in the HIT_SUITE_LIST is defined as eight-bit field The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of
signature algorithms as defined in Section Section 5.2.8 and hash
functions.
The ID field in the HIT_SUITE_LIST is defined as eight-bit field as
opposed to the four-bit HIT Suite ID and OGA field in the ORCHID. opposed to the four-bit HIT Suite ID and OGA field in the ORCHID.
This difference is a measure to accommodate larger HIT Suite IDs if This difference is a measure to accommodate larger HIT Suite IDs if
the 16 available values prove insufficient. In that case, one of the the 16 available values prove insufficient. In that case, one of the
16 values (0) will be used to indicate that four additional bits of 16 values, zero, will be used to indicate that four additional bits
the ORCHID will be used to encode the HIT Suite ID. Hence, the of the ORCHID will be used to encode the HIT Suite ID. Hence, the
current four-bit HIT Suite-IDs only use the four higher order bits in current four-bit HIT Suite-IDs only use the four higher order bits in
the ID field. Future documents may define the use of the four lower- the ID field. Future documents may define the use of the four lower-
order bits in the ID field. ^ order bits in the ID field.
The following HIT Suites ID are defined: The following HIT Suites ID are defined:
HIT Suite ID HIT Suite ID
RESERVED 0 RESERVED 0
RSA/DSA/SHA-1 1 (REQUIRED) RSA,DSA/SHA-1 1 (REQUIRED)
ECDSA/SHA-256 2 (RECOMMENDED) ECDSA/SHA-384 2 (RECOMMENDED)
ECDSA/SHA-384 3 (RECOMMENDED) ECDSA_LOW/SHA-1 3 (RECOMMENDED)
The HIT_SUITE_LIST parameter contains a list of the supported HIT The HIT_SUITE_LIST parameter contains a list of the supported HIT
suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST
in the signed part of the R1 packet. Based on the HIT_SUITE_LIST, in the signed part of the R1 packet. Based on the HIT_SUITE_LIST,
the Initiator can determine which source HITs are supported by the the Initiator can determine which source HITs are supported by the
Responder. Responder.
5.2.10. DH_GROUP_LIST 5.2.10. DH_GROUP_LIST
0 1 2 3 0 1 2 3
skipping to change at page 53, line 30 skipping to change at page 54, line 31
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 list of define DH Group IDs in the
DIFFIE_HELLMAN parameter. Each DH Group ID is one DIFFIE_HELLMAN parameter. Each DH Group ID is one
octet long. 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 it in the signed part of the R1 packet. packet, the Responder sends it in the signed part of the R1 packet.
The DH Group IDs in the DH_GROUP_LIST are listed in the order of The DH Group IDs in the DH_GROUP_LIST are listed in the order of
their preference of the host. DH Group IDs that are listed first are their preference of the host. DH Group IDs that are listed first are
preferred compared to the DH Group IDs listed later. The information preferred over the DH Group IDs listed later. The information in the
in the DH_GROUP_LIST allows the Responder to select the DH group DH_GROUP_LIST allows the Responder to select the DH group preferred
preferred by itself and the Initiator. Based on the DH_GROUP_LIST in by itself and the Initiator. Based on the DH_GROUP_LIST in the R1
the R1 packet, the Initiator can determine if the Responder has packet, the Initiator can determine if the Responder has selected the
selected the best possible choice based on the Initiator's and best possible choice based on the Initiator's and Responder's
Responder's preferences. If the Responder's choice differs from the preferences. If the Responder's choice differs from the best choice,
best choice, the Initiator can conclude that there was an attempted the Initiator can conclude that there was an attempted downgrade
downgrade attack. attack (see Section 4.1.7).
When selecting the DH group for the DIFFIE_HELLMAN parameter in the When selecting the DH group for the DIFFIE_HELLMAN parameter in the
R1 packet, the Responder MUST select the first DH Group ID in the R1 packet, the Responder MUST select the first DH Group ID in its
Responder's DH_GROUP_LIST that is contained in the Initiator's DH_GROUP_LIST in the R1 packet that is contained in the Initiator's
DH_GROUP_LIST. DH_GROUP_LIST in the I1 packet. The Responder MUST not select any
other DH Group ID that is contained in both lists because a downgrade
attack cannot be detected then.
5.2.11. HIP_MAC 5.2.11. 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 54, line 38 skipping to change at page 55, line 38
calculated not to cover any excluded parameters calculated not to cover any excluded parameters
when the HMAC is calculated. The size of the when the HMAC is calculated. The size of the
HMAC is the natural size of the hash computation HMAC is the natural size of the hash computation
output depending on the used hash function. output depending on the used hash function.
The HMAC uses RHASH as hash algorithm. The calculation and The HMAC uses RHASH as hash algorithm. The calculation and
verification process is presented in Section 6.4.1. verification process is presented in Section 6.4.1.
5.2.12. HIP_MAC_2 5.2.12. HIP_MAC_2
The parameter structure is the same as in Section 5.2.11. The fields The HIP_MAC_2 is a MAC of the packet and the HOST_ID parameter of the
are: sender while only the packet without HOST_ID is sent. The parameter
structure is the same as in Section 5.2.11. 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 parameter and any following parameters such HIP_MAC_2 parameter and any following parameters
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 parameter during the HMAC calculation. The checksum
checksum field MUST be set to zero and the HIP field MUST be set to zero and the HIP header length
header length in the HIP common header MUST be in the HIP common header MUST be calculated not to
calculated not to cover any excluded parameters cover any excluded parameters when the HMAC is
when the HMAC is calculated. The size of the calculated. The size of the HMAC is the natural
HMAC is the natural size of the hash computation size of the hash computation output depending on the
output depending on the used hash function. used hash function.
The HMAC uses RHASH as hash algorithm. The calculation and The HMAC uses RHASH as hash algorithm. The calculation and
verification process is presented in Section 6.4.1. verification process is presented in Section 6.4.1.
5.2.13. HIP_SIGNATURE 5.2.13. HIP_SIGNATURE
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
skipping to change at page 55, line 43 skipping to change at page 56, line 43
/ | Padding | / | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 61697 Type 61697
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
Padding Padding
SIG alg signature algorithm SIG alg signature algorithm
Signature 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.
The checksum field MUST be set to zero, and the HIP When the signature is calculated the checksum field
header length in the HIP common header MUST be MUST be set to zero, and the HIP header length in
calculated only to the beginning of the the HIP common header MUST be calculated only up to
HIP_SIGNATURE parameter when the signature is the beginning of the HIP_SIGNATURE parameter.
calculated.
The signature algorithms are defined in Section 5.2.8. The signature The signature algorithms are defined in Section 5.2.8. The signature
in the Signature field is encoded using the proper method depending in the Signature field is encoded using the method depending on the
on the signature algorithm (e.g., according to [RFC3110] in case of signature algorithm (e.g., according to [RFC3110] in case of RSA/
RSA/SHA-1, according to [RFC5702] in case of RSA/SHA-256, according SHA-1, according to [RFC5702] in case of RSA/SHA-256, according to
to [RFC2536] in case of DSA, or according to [fundamental-ecc] in [RFC2536] in case of DSA, or according to
case of ECDSA).
The HIP_SIGNATURE calculation and verification process is presented [I-D.mcgrew-fundamental-ecc] in case of ECDSA).
The HIP_SIGNATURE calculation and verification process are presented
in Section 6.4.2. in Section 6.4.2.
5.2.14. HIP_SIGNATURE_2 5.2.14. HIP_SIGNATURE_2
The parameter structure is the same as in Section 5.2.13. The fields The HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet
are: to allow R1 pre-creation. The parameter structure is the same as in
Section 5.2.13. The fields are:
Type 61633 Type 61633
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
Padding Padding
SIG alg signature algorithm SIG alg signature algorithm
Signature Within the R1 packet that contains the Signature Within the R1 packet that contains the
HIP_SIGNATURE_2 parameter, the Initiator's HIT, the HIP_SIGNATURE_2 parameter, the Initiator's HIT, the
checksum field, and the Opaque and Random #I fields checksum field, and the Opaque and Random #I fields
in the PUZZLE parameter MUST be set to zero while in the PUZZLE parameter MUST be set to zero while
computing the HIP_SIGNATURE_2 signature. Further, computing the HIP_SIGNATURE_2 signature. Further,
skipping to change at page 56, line 36 skipping to change at page 57, line 37
packet during the signature calculation, i.e., the packet during the signature calculation, i.e., the
HIP packet length points to the beginning of HIP packet length points to the beginning of
the HIP_SIGNATURE_2 parameter during signing and the HIP_SIGNATURE_2 parameter during signing and
verification. verification.
Zeroing the Initiator's HIT makes it possible to create R1 packets Zeroing the Initiator's HIT makes it possible to create R1 packets
beforehand, to minimize the effects of possible DoS attacks. Zeroing beforehand, to minimize the effects of possible DoS attacks. Zeroing
the Random #I and Opaque fields within the PUZZLE parameter allows the Random #I and Opaque fields within the PUZZLE parameter allows
these fields to be populated dynamically on precomputed R1s. these fields to be populated dynamically on precomputed R1s.
Signature calculation and verification follows the process in Signature calculation and verification follows the process defined in
Section 6.4.2. Section 6.4.2.
5.2.15. SEQ 5.2.15. SEQ
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update ID | | Update ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Update ID n /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 385 Type 385
Length 4 Length length in octets, excluding Type, Length, and
Padding
Update ID 32-bit sequence number Update ID 32-bit sequence number
The Update ID is an unsigned quantity, initialized by a host to zero The Update ID is an unsigned quantity, initialized by a host to zero
upon moving to ESTABLISHED state. The Update ID has scope within a upon moving to ESTABLISHED state. The Update ID has scope within a
single HIP association, and not across multiple associations or single HIP association, and not across multiple associations or
multiple hosts. The Update ID is incremented by one before each new multiple hosts. The Update ID is incremented by one before each new
UPDATE that is sent by the host; the first UPDATE packet originated UPDATE that is sent by the host; the first UPDATE packet originated
by a host has an Update ID of 0. by a host has an Update ID of 0.
5.2.16. ACK 5.2.16. ACK
skipping to change at page 58, line 41 skipping to change at page 59, line 41
Encrypted The data is encrypted using an encryption algorithm Encrypted The data is encrypted using an encryption algorithm
data as defined in the HIP_CIPHER parameter. data as defined in the HIP_CIPHER parameter.
The ENCRYPTED parameter encapsulates another parameter, the encrypted The ENCRYPTED parameter encapsulates another parameter, the encrypted
data, which holds one or more HIP parameters in block encrypted form. data, which holds one or more HIP parameters in block encrypted form.
Consequently, the first fields in the encapsulated parameter(s) are Consequently, the first fields in the encapsulated parameter(s) are
Type and Length of the first such parameter, allowing the contents to Type and Length of the first such parameter, allowing the contents to
be easily parsed after decryption. be easily parsed after decryption.
The field labelled "Encrypted data" consists of the output of one or The field labeled "Encrypted data" consists of the output of one or
more HIP parameters concatenated together that have been passed more HIP parameters concatenated together that have been passed
through an encryption algorithm. Each of these inner parameters is through an encryption algorithm. Each of these inner parameters is
padded according to the rules of Section 5.2.1 for padding individual padded according to the rules of Section 5.2.1 for padding individual
parameters. As a result, the concatenated parameters will be a block parameters. As a result, the concatenated parameters will be a block
of data that is 8-byte aligned. of data that is 8-byte aligned.
Some encryption algorithms require that the data to be encrypted must Some encryption algorithms require that the data to be encrypted must
be a multiple of the cipher algorithm block size. In this case, the be a multiple of the cipher algorithm block size. In this case, the
above block of data MUST include additional padding, as specified by above block of data MUST include additional padding, as specified by
the encryption algorithm. The size of the extra padding is selected the encryption algorithm. The size of the extra padding is selected
so that the length of the unencrypted data block is a multiple of the so that the length of the unencrypted data block is a multiple of the
cipher block size. The encryption algorithm may specify padding cipher block size. The encryption algorithm may specify padding
bytes other than zero; for example, AES [FIPS.197.2001] uses the bytes other than zero; for example, AES [FIPS.197.2001] uses the
PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the
remaining n bytes to fill the block each have the value n. This remaining n bytes to fill the block each have the value of n. This
yields an "unencrypted data" block that is transformed to an yields an "unencrypted data" block that is transformed to an
"encrypted data" block by the cipher suite. This extra padding added "encrypted data" block by the cipher suite. This extra padding added
to the set of parameters to satisfy the cipher block alignment rules to the set of parameters to satisfy the cipher block alignment rules
is not counted in HIP TLV length fields, and this extra padding is not counted in HIP TLV length fields, and this extra padding
should be removed by the cipher suite upon decryption. should be removed by the cipher suite upon decryption.
Note that the length of the cipher suite output may be smaller or Note that the length of the cipher suite output may be smaller or
larger than the length of the set of parameters to be encrypted, larger than the length of the set of parameters to be encrypted,
since the encryption process may compress the data or add additional since the encryption process may compress the data or add additional
padding to the data. padding to the data.
Once this encryption process is completed, the Encrypted data field Once this encryption process is completed, the Encrypted data field
is ready for inclusion in the Parameter. If necessary, additional is ready for inclusion in the Parameter. If necessary, additional
Padding for 8-byte alignment is then added according to the rules of Padding for 8-byte alignment is then added according to the rules of
Section 5.2.1. Section 5.2.1.
5.2.18. NOTIFICATION 5.2.18. NOTIFICATION
The NOTIFICATION parameter is used to transmit informational data, The NOTIFICATION parameter is used to transmit informational data,
such as error conditions and state transitions, to a HIP peer. A such as error conditions and state transitions, to a HIP peer. A
NOTIFICATION parameter may appear in the NOTIFY packet type. The use NOTIFICATION parameter may appear in NOTIFY packets. The use of the
of the NOTIFICATION parameter in other packet types is for further NOTIFICATION parameter in other packet types is for further study.
study.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Notify Message Type | | Reserved | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| / | /
/ Notification Data / / Notification Data /
skipping to change at page 62, line 29 skipping to change at page 63, line 29
Sent in response to a failure to validate the peer's Sent in response to a failure to validate the peer's
HIT from the corresponding HI. HIT from the corresponding HI.
BLOCKED_BY_POLICY 42 BLOCKED_BY_POLICY 42
The Responder is unwilling to set up an association The Responder is unwilling to set up an association
for some policy reason (e.g., received HIT is NULL for some policy reason (e.g., received HIT is NULL
and policy does not allow opportunistic mode). and policy does not allow opportunistic mode).
SERVER_BUSY_PLEASE_RETRY 44 RESPONDER_BUSY_PLEASE_RETRY 44
The Responder is unwilling to set up an association as it is The Responder is unwilling to set up an association as it is
suffering under some kind of overload and has chosen to shed load suffering under some kind of overload and has chosen to shed load
by rejecting the Initiator's request. The Initiator may retry; by rejecting the Initiator's request. The Initiator may retry;
however, the Initiator MUST find another (different) puzzle however, the Initiator MUST find another (different) puzzle
solution for any such retries. Note that the Initiator may need solution for any such retries. Note that the Initiator may need
to obtain a new puzzle with a new I1/R1 exchange. to obtain a new puzzle with a new I1/R1 exchange.
NOTIFY MESSAGES - STATUS TYPES Value NOTIFY MESSAGES - STATUS TYPES Value
------------------------------ ----- ------------------------------ -----
I2_ACKNOWLEDGEMENT 16384 I2_ACKNOWLEDGEMENT 16384
The Responder has an I2 from the Initiator but had to queue the The Responder has an I2 packet from the Initiator but had to
I2 for processing. The puzzle was correctly solved and the queue the I2 packet or processing. The puzzle was correctly
Responder is willing to set up an association but currently has a solved and the Responder is willing to set up an association but
number of I2s in the processing queue. R2 will be sent after the currently has a number of I2 packets in the processing queue. R2
I2 has been processed. are sent after the I2 packet has been processed.
5.2.19. ECHO_REQUEST_SIGNED 5.2.19. ECHO_REQUEST_SIGNED
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) | | Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 66, line 32 skipping to change at page 67, line 32
| 19 | CLOSE_ACK - the HIP Closing Acknowledgment | | 19 | CLOSE_ACK - the HIP Closing Acknowledgment |
| | Packet | | | Packet |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
Table 10: HIP packets and packet type numbers Table 10: HIP packets and packet type numbers
Packets consist of the fixed header as described in Section 5.1, Packets consist of the fixed header as described in Section 5.1,
followed by the parameters. The parameter part, in turn, consists of followed by the parameters. The parameter part, in turn, consists of
zero or more TLV-coded parameters. zero or more TLV-coded parameters.
In addition to the base packets, other packet types will 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 used operations. See Notation (Section 2.2) for used 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. This limits the size of the possible
additional data in the packet. additional data in the packet.
skipping to change at page 67, line 12 skipping to change at page 68, line 12
SRC HIT = Initiator's HIT SRC HIT = Initiator's HIT
DST HIT = Responder's HIT, or NULL DST HIT = Responder's HIT, or NULL
IP ( HIP ( DH_GROUP_LIST ) ) IP ( HIP ( DH_GROUP_LIST ) )
The I1 packet contains the fixed HIP header and the Initiator's The I1 packet contains the fixed HIP header and the Initiator's
DH_GROUP_LIST. DH_GROUP_LIST.
Valid control bits: none Valid control bits: none
The Initiator gets the Responder's HIT either from a DNS lookup of The Initiator receives the Responder's HIT either from a DNS lookup
the Responder's FQDN, from some other repository, or from a local of the Responder's FQDN, from some other repository, or from a local
table. If the Initiator does not know the Responder's HIT, it may table. If the Initiator does not know the Responder's HIT, it may
attempt to use opportunistic mode by using NULL (all zeros) as the attempt to use opportunistic mode by using NULL (all zeros) as the
Responder's HIT. See also "HIP Opportunistic Mode" (Section 4.1.8). Responder's HIT. See also "HIP Opportunistic Mode" (Section 4.1.8).
Since this packet is so easy to spoof even if it were signed, no Since this packet is so easy to spoof even if it were signed, no
attempt is made to add to its generation or processing cost. attempt is made to add to its generation or processing cost.
The Initiator includes a DH_GROUP_LIST parameter in the I1 to inform The Initiator includes a DH_GROUP_LIST parameter in the I1 packet to
the Responder of its preferred DH Group IDs. Note that the inform the Responder of its preferred DH Group IDs. Note that the
DH_GROUP_LIST in the I1 packet is not protected by a signature. DH_GROUP_LIST in the I1 packet is not protected by a signature.
Implementations MUST be able to handle a storm of received I1 Implementations MUST be able to handle a storm of received I1
packets, discarding those with common content that arrive within a packets, discarding those with common content that arrive within a
small time delta. small time delta.
5.3.2. R1 - the HIP Responder Packet 5.3.2. R1 - the HIP Responder Packet
The HIP header values for the R1 packet: The HIP header values for the R1 packet:
skipping to change at page 68, line 5 skipping to change at page 69, line 5
HIT_SUITE_LIST, HIT_SUITE_LIST,
DH_GROUP_LIST, DH_GROUP_LIST,
[ ECHO_REQUEST_SIGNED, ] [ ECHO_REQUEST_SIGNED, ]
HIP_SIGNATURE_2 ) HIP_SIGNATURE_2 )
<, ECHO_REQUEST_UNSIGNED >i) <, ECHO_REQUEST_UNSIGNED >i)
Valid control bits: A Valid control bits: A
If the Responder's HI is an anonymous one, the A control MUST be set. If the Responder's HI is an anonymous one, the A control MUST be set.
The Initiator's HIT MUST match the one received in I1. If the The Initiator's HIT MUST match the one received in the I1 packet. If
Responder has multiple HIs, the Responder's HIT used MUST match the Responder has multiple HIs, the Responder's HIT used MUST match
Initiator's request. If the Initiator used opportunistic mode, the Initiator's request. If the Initiator used opportunistic mode, the
Responder may select freely among its HIs. See also "HIP Responder may select freely among its HIs. See also "HIP
Opportunistic Mode" (Section 4.1.8). Opportunistic Mode" (Section 4.1.8).
The R1 generation counter is used to determine the currently valid The R1 packet generation counter is used to determine the currently
generation of puzzles. The value is increased periodically, and it valid generation of puzzles. The value is increased periodically,
is RECOMMENDED that it is increased at least as often as solutions to and it is RECOMMENDED that it is increased at least as often as
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 difficulty The Puzzle contains a Random #I and the difficulty K. The difficulty
K indicates the number of lower-order bits, in the puzzle hash 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 not 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 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 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. The Responder sends back its own preference based on which the I1 packet. The Responder sends back its own preference based on
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 I1 was Initiator to determine whether its own DH_GROUP_LIST in the sent I1
manipulated by an attacker. packet was manipulated by an attacker.
The Diffie-Hellman public value is ephemeral, and one value SHOULD be The Diffie-Hellman public value is ephemeral, and values SHOULD not
used only for one connection. Once the Responder has received a be reused across different HIP sessions. Once the Responder has
valid response to an R1 packet, that Diffie-Hellman value SHOULD be received a valid response to an R1 packet, that Diffie-Hellman value
deprecated. Because it is possible that the Responder has sent the SHOULD be deprecated. It it is possible that the Responder has sent
same Diffie-Hellman value to different hosts simultaneously in the same Diffie-Hellman value to different hosts simultaneously in
corresponding R1 packets, those responses should also be accepted. corresponding R1 packets and those responses should also be accepted.
However, as a defense against I1 storms, an implementation MAY However, as a defense against I1 packet storms, an implementation MAY
propose, and re-use if not 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
values and puzzles. values and puzzles.
Re-using Diffie-Hellman public keys opens up the potential security Re-using Diffie-Hellman public keys opens up the potential security
risk of more than one Initiator ending up with the same keying risk of more than one Initiator ending up with the same keying
material (due to faulty random number generators). Also, more than material (due to faulty random number generators). Also, more than
one Initiator using the same Responder public key half may lead to one Initiator using the same Responder public key half may lead to
potentially easier cryptographic attacks and to imperfect forward potentially easier cryptographic attacks and to imperfect forward
security. security.
However, these risks involved in re-using the same key are However, these risks involved in re-using the same key are
statistical; that is, the authors are not aware of any mechanism that statistical; that is, the authors are not aware of any mechanism that
would allow manipulation of the protocol so that the risk of the re- would allow manipulation of the protocol so that the risk of the re-
use of any given Responder Diffie-Hellman public key would differ use of any given Responder Diffie-Hellman public key would differ
from the base probability. Consequently, it is RECOMMENDED that from the base probability. Consequently, it is RECOMMENDED that
implementations avoid re-using the same DH key with multiple Responders avoid re-using the same DH key with multiple Initiators,
Initiators, but because the risk is considered statistical and not but because the risk is considered statistical and not known to be
known to be manipulable, the implementations MAY re-use a key in manipulable, the implementations MAY re-use a key in order to ease
order to ease resource-constrained implementations and to increase resource-constrained implementations and to increase the probability
the probability of successful communication with legitimate clients of successful communication with legitimate clients even under an I1
even under an I1 storm. In particular, when it is too expensive to packet storm. In particular, when it is too expensive to generate
generate enough precomputed R1 packets to supply each potential enough precomputed R1 packets to supply each potential Initiator with
Initiator with a different DH key, the Responder MAY send the same DH a different DH key, the Responder MAY send the same DH key to several
key to several Initiators, thereby creating the possibility of Initiators, thereby creating the possibility of multiple legitimate
multiple legitimate Initiators ending up using the same Responder- Initiators ending up using the same Responder-side public key.
side public key. However, as soon as the Responder knows that it However, as soon as the Responder knows that it will use a particular
will use a particular DH key, it SHOULD stop offering it. This DH key, it SHOULD stop offering it. This design is aimed to allow
design is aimed to allow resource-constrained Responders to offer resource-constrained Responders to offer services under I1 packet
services under I1 storms and to simultaneously make the probability storms and to simultaneously make the probability of DH key re-use
of DH key re-use both statistical and as low as possible. both statistical and as low as possible.
If a future version of this protocol is considered, we strongly If a future version of this protocol is considered, we strongly
recommend that these issues be studied again. Especially, the recommend that these issues be studied again. Especially, the
current design allows hosts to become potentially more vulnerable to current design allows hosts to become potentially more vulnerable to
a statistical, low-probability problem during I1 storm attacks than a statistical, low-probability problem during I1 packet storm attacks
what they are if no attack is taking place; whether this is than what they are if no attack is taking place; whether this is
acceptable or not should be reconsidered in the light of any new acceptable or not should be reconsidered in the light of any new
experience gained. experience gained.
The HIP_CIPHER contains the encryption algorithms supported by the The HIP_CIPHER contains the encryption algorithms supported by the
Responder to encrypt the ENCRYPTED parameter, in the order of Responder to encrypt the ENCRYPTED parameter, in the order of
preference. All implementations MUST support AES [RFC3602]. preference. All implementations MUST support AES [RFC3602].
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 is suitable. determine whether its own source HIT matches any suite supported by
the Responder.
The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED contains data that The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED contains data that
the sender wants to receive unmodified in the corresponding response the sender wants to receive unmodified in the corresponding response
packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED
parameter. parameter.
The signature is calculated over the whole HIP envelope, after The signature is calculated over the whole HIP envelope, after
setting the Initiator's HIT, header checksum, as well as the Opaque setting the Initiator's HIT, header checksum, as well as the Opaque
field and the Random #I in the PUZZLE parameter temporarily to zero, field and the Random #I in the PUZZLE parameter temporarily to zero,
and excluding any parameters that follow the signature, as described and excluding any parameters that follow the signature, as described
in Section 5.2.14. This allows the Responder to use precomputed R1s. in Section 5.2.14. This allows the Responder to use precomputed R1s.
The Initiator SHOULD validate this signature. It SHOULD check that The Initiator SHOULD validate this signature. It MUST check that the
the Responder's HI received matches with the one expected, if any. Responder's HI matches with the one expected, if any.
5.3.3. I2 - the Second HIP Initiator Packet 5.3.3. I2 - the Second HIP Initiator Packet
The HIP header values for the I2 packet: The HIP header values for the I2 packet:
Header: Header:
Type = 3 Type = 3
SRC HIT = Initiator's HIT SRC HIT = Initiator's HIT
DST HIT = Responder's HIT DST HIT = Responder's HIT
skipping to change at page 70, line 42 skipping to change at page 71, line 42
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 transform selected by
the Initiator, that will be used to encrypt the ENCRYPTED parameter. the Initiator, that it uses to encrypt the ENCRYPTED parameter. The
The chosen cipher MUST correspond to one offered by the Responder in chosen cipher MUST correspond to one of the ciphers offered by the
the R1. All implementations MUST support AES m [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. parameter.
The HMAC is calculated over the whole HIP envelope, excluding any The HMAC is calculated over the whole HIP envelope, excluding any
parameters after the HIP_MAC, as described in Section 6.4.1. The parameters after the HIP_MAC, as described in Section 6.4.1. The
Responder MUST validate the HIP_MAC. Responder MUST validate the HIP_MAC.
The signature is calculated over the whole HIP envelope, excluding The signature is calculated over the whole HIP envelope, excluding
any parameters after the HIP_SIGNATURE, as described in any parameters after the HIP_SIGNATURE, as described in
Section 5.2.13. The Responder MUST validate this signature. It MAY Section 5.2.13. The Responder MUST validate this signature. The
use either the HI in the packet or the HI acquired by some other Responder uses the HI in the packet or a HI acquired by some other
means. means for verifying the signature.
5.3.4. R2 - the Second HIP Responder Packet 5.3.4. R2 - the Second HIP Responder Packet
The HIP header values for the R2 packet: The HIP header values for the R2 packet:
Header: Header:
Packet Type = 4 Packet Type = 4
SRC HIT = Responder's HIT SRC HIT = Responder's HIT
DST HIT = Initiator's HIT DST HIT = Initiator's HIT
skipping to change at page 72, line 8 skipping to change at page 73, line 8
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 ACK the UPDATE. of a SEQ parameter indicates that the receiver MUST acknowledge the
An UPDATE that does not contain a SEQ parameter is simply an ACK of a the UPDATE. An UPDATE that does not contain a SEQ parameter is
previous UPDATE and itself MUST NOT be ACKed. simply an acknowledgment of a previous UPDATE and itself MUST NOT be
acknowledged by a separate ACK.
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 ACK more than one UPDATE packet at a ACKed. A host MAY choose to acknowledge more than one UPDATE packet
time; e.g., the ACK may contain the last two SEQ values received, for at a time; e.g., the ACK may contain the last two SEQ values
robustness to ACK loss. ACK values are not cumulative; each received received, for resilience against ACK loss. ACK values are not
unique SEQ value requires at least one corresponding ACK value in cumulative; each received unique SEQ value requires at least one
reply. Received ACKs that are redundant are ignored. corresponding ACK value in reply. Received ACKs that are redundant
are ignored. Hosts MUST implement the processing of ACKS with
multiple SEQ numbers even if they do not implement sending ACKs with
multiple SEQ numbers.
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 is being piggybacked on an outgoing UPDATE. In
general, UPDATEs carrying SEQ SHOULD be ACKed upon completion of the general, UPDATEs carrying SEQ SHOULD be ACKed upon completion of the
processing of the UPDATE. A host MAY choose to hold the UPDATE processing of the UPDATE. A host MAY choose to hold the UPDATE
carrying ACK for a short period of time to allow for the possibility carrying ACK for a short period of time to allow for the possibility
of piggybacking the ACK parameter, in a manner similar to TCP delayed of piggybacking the ACK parameter, in a manner similar to TCP delayed
acknowledgments. acknowledgments.
A sender MAY choose to forgo reliable transmission of a particular A sender MAY choose to forgo reliable transmission of a particular
skipping to change at page 72, line 44 skipping to change at page 73, line 48
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
The NOTIFY packet is OPTIONAL. The NOTIFY packet MAY be used to The NOTIFY packet is OPTIONAL. The NOTIFY packet MAY be used to
provide information to a peer. Typically, NOTIFY is used to indicate provide information to a peer. Typically, NOTIFY is used to indicate
some type of protocol error or negotiation failure. NOTIFY packets some type of protocol error or negotiation failure. NOTIFY packets
are unacknowledged. The receiver can handle the packet only as are unacknowledged. The receiver can handle the packet only as
informational, and SHOULD NOT change its HIP state (Section 4.4.2) informational, and SHOULD NOT change its HIP state (see
based purely on a received NOTIFY packet. Section 4.4.2) based purely on a received 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 73, line 35 skipping to change at page 74, line 35
IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) )
Valid control bits: none Valid control bits: none
The sender MUST include an ECHO_REQUEST_SIGNED used to validate The sender MUST include an ECHO_REQUEST_SIGNED used to validate
CLOSE_ACK received in response, and both an HIP_MAC and a signature CLOSE_ACK received in response, and both an HIP_MAC and a signature
(calculated over the whole HIP envelope). (calculated over the whole HIP envelope).
The receiver peer MUST validate both the HIP_MAC and the signature if The receiver peer MUST validate both the HIP_MAC and the signature if
it has a HIP association state, and MUST reply with a CLOSE_ACK it has state for a HIP association, and MUST reply with a CLOSE_ACK
containing an ECHO_RESPONSE_SIGNED corresponding to the received containing an ECHO_RESPONSE_SIGNED corresponding to the received
ECHO_REQUEST_SIGNED. ECHO_REQUEST_SIGNED.
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet
The HIP header values for the CLOSE_ACK packet: The HIP header values for the CLOSE_ACK packet:
Header: Header:
Packet Type = 19 Packet Type = 19
SRC HIT = Sender's HIT SRC HIT = Sender's HIT
skipping to change at page 74, line 16 skipping to change at page 75, line 16
The receiver peer MUST validate both the HMAC and the signature. The receiver peer MUST validate both the HMAC and the signature.
5.4. ICMP Messages 5.4. ICMP Messages
When a HIP implementation detects a problem with an incoming packet, When a HIP implementation detects a problem with an incoming packet,
and it either cannot determine the identity of the sender of the and it either cannot determine the identity of the sender of the
packet or does not have any existing HIP association with the sender packet or does not have any existing HIP association with the sender
of the packet, it MAY respond with an ICMP packet. Any such replies of the packet, it MAY respond with an ICMP packet. Any such replies
MUST be rate-limited as described in [RFC2463]. In most cases, the MUST be rate-limited as described in [RFC2463]. In most cases, the
ICMP packet will have the Parameter Problem type (12 for ICMPv4, 4 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for
for ICMPv6), with the Pointer field pointing to the field that caused ICMPv6), with the Pointer field pointing to the field that caused the
the ICMP message to be generated. ICMP message to be generated.
5.4.1. Invalid Version 5.4.1. Invalid Version
If a HIP implementation receives a HIP packet that has an If a HIP implementation receives a HIP packet that has an
unrecognized HIP version number, it SHOULD respond, rate-limited, unrecognized HIP version number, it SHOULD respond, rate-limited,
with an ICMP packet with type Parameter Problem, the Pointer pointing with an ICMP packet with type Parameter Problem, with the Pointer
to the VER./RES. byte in the HIP header. pointing to the VER./RES. byte in the HIP header.
5.4.2. Other Problems with the HIP Header and Packet Structure 5.4.2. Other Problems with the HIP Header and Packet Structure
If a HIP implementation receives a HIP packet that has other If a HIP implementation receives a HIP packet that has other
unrecoverable problems in the header or packet format, it MAY unrecoverable problems in the header or packet format, it MAY
respond, rate-limited, with an ICMP packet with type Parameter respond, rate-limited, with an ICMP packet with type Parameter
Problem, the Pointer pointing to the field that failed to pass the Problem, the Pointer pointing to the field that failed to pass the
format checks. However, an implementation MUST NOT send an ICMP format checks. However, an implementation MUST NOT send an ICMP
message if the checksum fails; instead, it MUST silently drop the message if the checksum fails; instead, it MUST silently drop the
packet. packet.
skipping to change at page 75, line 13 skipping to change at page 76, line 13
message exceeds the typical ICMPv4 message size as defined in message exceeds the typical ICMPv4 message size as defined in
[RFC0792]. [RFC0792].
5.4.4. Non-Existing HIP Association 5.4.4. Non-Existing HIP Association
If a HIP implementation receives a CLOSE or UPDATE packet, or any If a HIP implementation receives a CLOSE or UPDATE packet, or any
other packet whose handling requires an existing association, that other packet whose handling requires an existing association, that
has either a Receiver or Sender HIT that does not match with any has either a Receiver or Sender HIT that does not match with any
existing HIP association, the implementation MAY respond, rate- existing HIP association, the implementation MAY respond, rate-
limited, with an ICMP packet with the type Parameter Problem, and limited, with an ICMP packet with the type Parameter Problem. The
with the Pointer pointing to the beginning of the first HIT that does Pointer of the ICMP Parameter Problem packet is set pointing to the
not match. beginning of the first HIT that does not match.
A host MUST NOT reply with such an ICMP if it receives any of the A host MUST NOT reply with such an ICMP if it receives any of the
following messages: I1, R2, I2, R2, and NOTIFY. When introducing new following messages: I1, R2, I2, R2, and NOTIFY packet. When
packet types, a specification SHOULD define the appropriate rules for introducing new packet types, a specification SHOULD define the
sending or not sending this kind of ICMP reply. appropriate rules for sending or not sending this kind of ICMP reply.
6. Packet Processing 6. Packet Processing
Each host is assumed to have a single HIP protocol implementation Each host is assumed to have a single HIP protocol implementation
that manages the host's HIP associations and handles requests for new that manages the host's HIP associations and handles requests for new
ones. Each HIP association is governed by a conceptual state ones. Each HIP association is governed by a conceptual state
machine, with states defined above in Section 4.4. The HIP machine, with states defined above in Section 4.4. The HIP
implementation can simultaneously maintain HIP associations with more implementation can simultaneously maintain HIP associations with more
than one host. Furthermore, the HIP implementation may have more than one host. Furthermore, the HIP implementation may have more
than one active HIP association with another host; in this case, HIP than one active HIP association with another host; in this case, HIP
skipping to change at page 76, line 13 skipping to change at page 77, line 13
implementation, the identifier provided to the application may be implementation, the identifier provided to the application may be
different; for example, it can be a HIT or an IP address. different; for example, it can be a HIT or an IP address.
The exact format and method for transferring the data from the source The exact format and method for transferring the data from the source
HIP host to the destination HIP host is defined in the corresponding HIP host to the destination HIP host is defined in the corresponding
transport format document. The actual data is transferred in the transport format document. The actual data is transferred in the
network using the appropriate source and destination IP addresses. network using the appropriate source and destination IP addresses.
In this document, conceptual processing rules are defined only for In this document, conceptual processing rules are defined only for
the base case where both hosts have only single usable IP addresses; the base case where both hosts have only single usable IP addresses;
the multi-address multi-homing case will be specified separately. the multi-address multi-homing case is specified separately.
The following conceptual algorithm describes the steps that are The following conceptual algorithm describes the steps that are
required for handling outgoing datagrams destined to a HIT. required for handling outgoing datagrams destined to a HIT.
1. If the datagram has a specified source address, it MUST be a HIT. 1. If the datagram has a specified source address, it MUST be a HIT.
If it is not, the implementation MAY replace the source address If it is not, the implementation MAY replace the source address
with a HIT. Otherwise, it MUST drop the packet. with a HIT. Otherwise, it MUST drop the packet.
2. If the datagram has an unspecified source address, the 2. If the datagram has an unspecified source address, the
implementation must choose a suitable source HIT for the implementation must choose a suitable source HIT for the
skipping to change at page 77, line 19 skipping to change at page 78, line 19
2. The specific transport format is unwrapped, in a way depending on 2. The specific transport format is unwrapped, in a way depending on
the transport format, yielding a packet that looks like a the transport format, yielding a packet that looks like a
standard (unencrypted) IP packet. If possible, this step SHOULD standard (unencrypted) IP packet. If possible, this step SHOULD
also verify that the packet was indeed (once) sent by the remote also verify that the packet was indeed (once) sent by the remote
HIP host, as identified by the HIP association. HIP host, as identified by the HIP association.
Depending on the used transport mode, the verification method can Depending on the used transport mode, the verification method can
vary. While the HI (as well as HIT) is used as the higher-layer vary. While the HI (as well as HIT) is used as the higher-layer
identifier, the verification method has to verify that the data identifier, the verification method has to verify that the data
packet was sent by a node identity and that the actual identity packet was sent by a the correct node identity and that the
maps to this particular HIT. When using ESP transport format actual identity maps to this particular HIT. When using ESP
[RFC5202], the verification is done using the SPI value in the transport format [I-D.ietf-hip-rfc5202-bis], the verification is
data packet to find the corresponding SA with associated HIT and done using the SPI value in the data packet to find the
key, and decrypting the packet with that associated key. corresponding SA with associated HIT and key, and decrypting the
packet with that associated key.
3. The IP addresses in the datagram are replaced with the HITs 3. The IP addresses in the datagram are replaced with the HITs
associated with the HIP association. Note that this IP-address- associated with the HIP association. Note that this IP-address-
to-HIT conversion step MAY also be performed at some other point to-HIT conversion step MAY also be performed at some other point
in the stack. in the stack.
4. The datagram is delivered to the upper layer. When 4. The datagram is delivered to the upper layer (e.g., UDP or TCP).
demultiplexing the datagram, the right upper-layer socket is When demultiplexing the datagram, the right upper-layer socket is
based on the HITs. based on the HITs.
6.3. Solving the Puzzle 6.3. Solving the Puzzle
This subsection describes the puzzle-solving details. This subsection describes the details for solving the puzzle.
In R1, the values I and K are sent in network byte order. Similarly, In the R1 packet, the values I and K are sent in network byte order.
in I2, the values I and J are sent in network byte order. The hash Similarly, in the I2 packet, the values I and J are sent in network
is created by concatenating, in network byte order, the following byte order. The hash is created by concatenating, in network byte
data, in the following order and using the RHASH algorithm: order, the following data, in the following order and using the RHASH
algorithm:
n-bit random value I (where n is RHASH_len), in network byte n-bit random value I (where n is RHASH_len), in network byte
order, as appearing in R1 and I2. order, as appearing in the R1 and I2 packets.
128-bit Initiator's HIT, in network byte order, as appearing in 128-bit Initiator's HIT, in network byte order, as appearing in
the HIP Payload in R1 and I2. the HIP Payload in the R1 and I2 packets.
128-bit Responder's HIT, in network byte order, as appearing in 128-bit Responder's HIT, in network byte order, as appearing in
the HIP Payload in R1 and I2. the HIP Payload in the R1 and I2 packets.
n-bit random value J (where n is RHASH_len), in network byte n-bit random value J (where n is RHASH_len), in network byte
order, as appearing in I2. order, as appearing in the I2 packet.
In order to be a valid response puzzle, the K low-order bits of the In a valid response puzzle, the K low-order bits of the resulting
resulting RHASH digest must be zero. RHASH digest MUST be zero.
Notes: Notes:
i) The length of the data to be hashed is variable depending on i) The length of the data to be hashed is variable depending on
the output length of the Responder's hash function RHASH. the output length of the Responder's hash function RHASH.
ii) All the data in the hash input MUST be in network byte order. ii) All the data in the hash input MUST be in network byte order.
iii) The order of the Initiator's and Responder's HITs are iii) The order of the Initiator's and Responder's HITs are
different in the R1 and I2 packets; see Section 5.1. Care must be different in the R1 and I2 packets; see Section 5.1. Care must be
taken to copy the values in the right order to the hash input. taken to copy the values in the right order to the hash input.
iv) For a puzzle I, there may exist multiple valid puzzle
solutions J.
The following procedure describes the processing steps involved, The following procedure describes the processing steps involved,
assuming that the Responder chooses to precompute the R1 packets: assuming that the Responder chooses to precompute the R1 packets:
Precomputation by the Responder: Precomputation by the Responder:
Sets up the puzzle difficulty K. Sets up the puzzle difficulty K.
Creates a signed R1 and caches it. Creates a signed R1 and caches it.
Responder: Responder:
Selects a suitable cached R1. Selects a suitable cached R1.
Generates a random number I. Generates a random number I.
skipping to change at page 79, line 8 skipping to change at page 80, line 8
Responder: Responder:
Verifies that the received I is a saved one. Verifies that the received I is a saved one.
Finds the right K based on I. Finds the right K based on I.
Computes V := Ltrunc( RHASH( I | HIT-I | HIT-R | J ), K ) Computes V := Ltrunc( RHASH( I | HIT-I | HIT-R | J ), K )
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. HIP_MAC_2, HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. 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 and HIP_MAC parameter are contained in other HIP
control packets.
6.4.1. HMAC Calculation 6.4.1. HMAC Calculation
The HMAC uses RHASH as underlying hash function. The RHASH depends
on the HIT Suite of the Responder. Hence, HMAC-SHA-1 [RFC2404] is
used for HIT Suites RSA/DSA/SAH-1 and ECDSA_LOW/SHA-1 and HMAC-SHA-
256 [RFC4868] for 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
parameters. When processing HIP_MAC_2, the difference is that the parameters. When processing HIP_MAC_2, the difference is that the
HIP_MAC calculation includes a pseudo HOST_ID field containing the HIP_MAC calculation includes a pseudo HOST_ID field containing the
Responder's information as sent in the R1 packet earlier. Responder's information as sent in the R1 packet earlier.
Both the Initiator and the Responder should take some care when Both the Initiator and the Responder should take some care when
verifying or calculating the HIP_MAC_2. Specifically, the Responder verifying or calculating the HIP_MAC_2. Specifically, the Initiator
should preserve other parameters than the HOST_ID when sending the has to preserve the HOST_ID exactly as it was received in the R1
R2. Also, the Initiator has to preserve the HOST_ID exactly as it packet until it receives the HIP_MAC_2 in the R2 packet.
was received in the R1 packet.
The scope of the calculation for HIP_MAC and HIP_MAC_2 is: The scope of the calculation for HIP_MAC and HIP_MAC_2 is:
HMAC: { HIP header | [ Parameters ] } HMAC: { HIP header | [ Parameters ] }
where Parameters include all HIP parameters of the packet that is where Parameters include all HIP parameters of the packet that is
being calculated with Type values from 1 to (HIP_MAC's Type value - being calculated with Type values ranging from 1 to (HIP_MAC's Type
1) and exclude parameters with Type values greater or equal to value - 1) and exclude parameters with Type values greater or equal
HIP_MAC's Type value. to HIP_MAC's Type value.
During HIP_MAC calculation, the following applies: During HIP_MAC calculation, the following applies:
o In the HIP header, the Checksum field is set to zero. o In the HIP header, the Checksum field is set to zero.
o In the HIP header, the Header Length field value is calculated to o In the HIP header, the Header Length field value is calculated to
the beginning of the HIP_MAC parameter. the beginning of the HIP_MAC parameter.
Parameter order is described in Section 5.2.1. Parameter order is described in Section 5.2.1.
skipping to change at page 80, line 52 skipping to change at page 82, line 10
7. Recalculate the Length field in the HIP header. 7. Recalculate the Length field in the HIP header.
Packet receiver: Packet receiver:
1. Verify the HIP header Length field. 1. Verify the HIP header Length field.
2. Remove the HIP_MAC or HIP_MAC_2 parameter, as well as all other 2. Remove the HIP_MAC or HIP_MAC_2 parameter, as well as all other
parameters that follow it with greater Type value including parameters that follow it with greater Type value including
possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the
contents if they will be needed later. contents if they are needed later.
3. In case of HIP_MAC_2, build and add a HOST_ID parameter (with 3. In case of HIP_MAC_2, build and add a HOST_ID parameter (with
Responder information) to the packet. The HOST_ID parameter Responder information) to the packet. The HOST_ID parameter
should be identical to the one previously received from the should be identical to the one previously received from the
Responder. Responder.
4. Recalculate the HIP packet length in the HIP header and clear the 4. Recalculate the HIP packet length in the HIP header and clear the
Checksum field (set it to all zeros). In case of HIP_MAC_2, the Checksum field (set it to all zeros). In case of HIP_MAC_2, the
length is calculated with the added HOST_ID parameter. length is calculated with the added HOST_ID parameter.
skipping to change at page 81, line 26 skipping to change at page 82, line 33
6. Set Checksum and Header Length field in the HIP header to 6. Set Checksum and Header Length field in the HIP header to
original values. original values.
7. In case of HIP_MAC_2, remove the HOST_ID parameter from the 7. In case of HIP_MAC_2, remove the HOST_ID parameter from the
packet before further processing. packet before further processing.
6.4.2. Signature Calculation 6.4.2. Signature Calculation
The following process applies both to the HIP_SIGNATURE and The following process applies both to the HIP_SIGNATURE and
HIP_SIGNATURE_2 parameters. When processing HIP_SIGNATURE_2, the HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2, the
only difference is that instead of HIP_SIGNATURE parameter, the only difference is that instead of the HIP_SIGNATURE parameter, the
HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE
Opaque and Random #I fields are cleared (set to all zeros) before Opaque and Random #I fields are cleared (set to all zeros) before
computing the signature. The HIP_SIGNATURE parameter is defined in computing the signature. The HIP_SIGNATURE parameter is defined in
Section 5.2.13 and the HIP_SIGNATURE_2 parameter in Section 5.2.14. Section 5.2.13 and the HIP_SIGNATURE_2 parameter in Section 5.2.14.
The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2
is: is:
HIP_SIGNATURE: { HIP header | [ Parameters ] } HIP_SIGNATURE: { HIP header | [ Parameters ] }
where Parameters include all HIP parameters for the packet that is where Parameters include all HIP parameters for the packet that is
being calculated with Type values from 1 to (HIP_SIGNATURE's Type being calculated with Type values from 1 to (HIP_SIGNATURE's Type
value - 1). value - 1).
During signature calculation, the following apply: During signature calculation, the following applies:
o In the HIP header, the Checksum field is set to zero. o In the HIP header, the Checksum field is set to zero.
o In the HIP header, the Header Length field value is calculated to o In the HIP header, the Header Length field value is calculated to
the beginning of the HIP_SIGNATURE parameter. the beginning of the HIP_SIGNATURE parameter.
Parameter order is described in Section 5.2.1. The parameter order is described in Section 5.2.1.
HIP_SIGNATURE_2: { HIP header | [ Parameters ] } HIP_SIGNATURE_2: { HIP header | [ Parameters ] }
where Parameters include all HIP parameters for the packet that is where Parameters include all HIP parameters for the packet that is
being calculated with Type values from 1 to (HIP_SIGNATURE_2's Type being calculated with Type values ranging from 1 to
value - 1). (HIP_SIGNATURE_2's Type value - 1).
During signature calculation, the following apply: During signature calculation, the following apply:
o In the HIP header, the Initiator's HIT field and Checksum fields o In the HIP header, the Initiator's HIT field and Checksum fields
are set to zero. are set to zero.
o In the HIP header, the Header Length field value is calculated to o In the HIP header, the Header Length field value is calculated to
the beginning of the HIP_SIGNATURE_2 parameter. the beginning of the HIP_SIGNATURE_2 parameter.
o PUZZLE parameter's Opaque and Random #I fields are set to zero. o PUZZLE parameter's Opaque and Random #I fields are set to zero.
Parameter order is described in Section 5.2.1. Parameter order is described in Section 5.2.1.
Signature calculation and verification process (the process applies The signature calculation and verification process (the process
both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in the case where applies both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in the case
HIP_SIGNATURE_2 is separately mentioned): where HIP_SIGNATURE_2 is separately mentioned) is as follows:
Packet sender: Packet sender:
1. Create the HIP packet without the HIP_SIGNATURE parameter or any 1. Create the HIP packet without the HIP_SIGNATURE parameter or any
parameters that follow the HIP_SIGNATURE parameter. other parameters that follow the HIP_SIGNATURE parameter.
2. Calculate the Length field and zero the Checksum field in the HIP 2. Calculate the Length field and zero the Checksum field in the HIP
header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in
the HIP header as well as PUZZLE parameter's Opaque and Random #I the HIP header as well as PUZZLE parameter's Opaque and Random #I
fields to zero. fields to zero.
3. Compute the signature using the private key corresponding to the 3. Compute the signature using the private key corresponding to the
Host Identifier (public key). Host Identifier (public key).
4. Add the HIP_SIGNATURE parameter to the packet. 4. Add the HIP_SIGNATURE parameter to the packet.
5. Add any parameters that follow the HIP_SIGNATURE parameter. 5. Add any parameters that follow the HIP_SIGNATURE parameter.
6. Recalculate the Length field in the HIP header, and calculate the 6. Recalculate the Length field in the HIP header, and calculate the
Checksum field. Checksum field.
Packet receiver: Packet receiver:
1. Verify the HIP header Length field. 1. Verify the HIP header Length field and checksum.
2. Save the contents of the HIP_SIGNATURE parameter and any 2. Save the contents of the HIP_SIGNATURE parameter and any other
parameters following the HIP_SIGNATURE parameter and remove them parameters following the HIP_SIGNATURE parameter and remove them
from the packet. from the packet.
3. Recalculate the HIP packet Length in the HIP header and clear the 3. Recalculate the HIP packet Length in the HIP header and clear the
Checksum field (set it to all zeros). In case of Checksum field (set it to all zeros). In case of
HIP_SIGNATURE_2, set Initiator's HIT field in HIP header as well HIP_SIGNATURE_2, set Initiator's HIT field in the HIP header as
as PUZZLE parameter's Opaque and Random #I fields to zero. well as PUZZLE parameter's Opaque and Random #I fields to zero.
4. Compute the signature and verify it against the received 4. Compute the signature and verify it against the received
signature using the packet sender's Host Identifier (public key). signature using the packet sender's Host Identifier (public key).
5. Restore the original packet by adding removed parameters (in step 5. Restore the original packet by adding removed parameters (in step
2) and resetting the values that were set to zero (in step 3). 2) and resetting the values that were set to zero (in step 3).
The verification can use either the HI received from a HIP packet, The verification can use either the HI received from a HIP packet,
the HI from a DNS query, if the FQDN has been received in the HOST_ID the HI from a DNS query, if the FQDN has been received in the HOST_ID
packet, or one received by some other means. packet, or one received by some other means.
6.5. HIP KEYMAT Generation 6.5. HIP KEYMAT Generation
HIP keying material is derived from the Diffie-Hellman session key, HIP keying material is derived from the Diffie-Hellman session key,
Kij, produced during the HIP base exchange (Section 4.1.3). The Kij, produced during the HIP base exchange (see Section 4.1.3). The
Initiator has Kij during the creation of the I2 packet, and the Initiator has Kij during the creation of the I2 packet, and the
Responder has Kij once it receives the I2 packet. This is why I2 can Responder has Kij once it receives the I2 packet. This is why I2 can
already contain encrypted information. already contain encrypted information.
The KEYMAT is derived by feeding Kij into HKDF [RFC5869] using the The KEYMAT is derived by feeding Kij into HKDF [RFC5869] using the
RHASH hash function. RHASH hash function.
where where
info = sort(HIT-I | HIT-R) info = sort(HIT-I | HIT-R)
salt = I | J salt = I | J
Sort(HIT-I | HIT-R) is defined as the network byte order Sort(HIT-I | HIT-R) is defined as the network byte order
concatenation of the two HITs, with the smaller HIT preceding the concatenation of the two HITs, with the smaller HIT preceding the
larger HIT, resulting from the numeric comparison of the two HITs larger HIT, resulting from the numeric comparison of the two HITs
interpreted as positive (unsigned) 128-bit integers in network byte interpreted as positive (unsigned) 128-bit integers in network byte
order. order.
I and J values are from the puzzle and its solution that were The I and J values are from the puzzle and its solution that were
exchanged in R1 and I2 messages when this HIP association was set up. exchanged in R1 and I2 messages when this HIP association was set up.
Both hosts have to store I and J values for the HIP association for Both hosts have to store I and J values for the HIP association for
future use. future use.
The initial keys are drawn sequentially in the order that is The initial keys are drawn sequentially in the order that is
determined by the numeric comparison of the two HITs, with comparison determined by the numeric comparison of the two HITs, with comparison
method described in the previous paragraph. HOST_g denotes the host method described in the previous paragraph. HOST_g denotes the host
with the greater HIT value, and HOST_l the host with the lower HIT with the greater HIT value, and HOST_l the host with the lower HIT
value. value.
The drawing order for initial keys: The drawing order for the initial keys is as follows:
HIP-gl encryption key for HOST_g's outgoing HIP packets HIP-gl encryption key for HOST_g's outgoing HIP packets
HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets
HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP
packets packets
HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets
skipping to change at page 84, line 45 skipping to change at page 85, line 51
An implementation may originate a HIP exchange to another host based An implementation may originate a HIP exchange to another host based
on a local policy decision, usually triggered by an application on a local policy decision, usually triggered by an application
datagram, in much the same way that an IPsec IKE key exchange can datagram, in much the same way that an IPsec IKE key exchange can
dynamically create a Security Association. Alternatively, a system dynamically create a Security Association. Alternatively, a system
may initiate a HIP exchange if it has rebooted or timed out, or may initiate a HIP exchange if it has rebooted or timed out, or
otherwise lost its HIP state, as described in Section 4.5.4. otherwise lost its HIP state, as described in Section 4.5.4.
The implementation prepares an I1 packet and sends it to the IP The implementation prepares an I1 packet and sends it to the IP
address that corresponds to the peer host. The IP address of the address that corresponds to the peer host. The IP address of the
peer host may be obtained via conventional mechanisms, such as DNS peer host may be obtained via conventional mechanisms, such as DNS
lookup. The I1 contents are specified in Section 5.3.1. The lookup. The I1 packet contents are specified in Section 5.3.1. The
selection of which Host Identity to use, if a host has more than one selection of which source or destination Host Identity to use, if a
to choose from, is typically a policy decision. Initiator or Responder has more than one to choose from, is typically
a policy decision.
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
initiating a HIP exchange: initiating a HIP exchange:
1. The Initiator gets one or more of the Responder's HITs and one or 1. The Initiator receives one or more of the Responder's HITs and
more addresses either from a DNS lookup of the Responder's FQDN, one or more addresses either from a DNS lookup of the Responder's
from some other repository, or from a local table. If the FQDN, from some other repository, or from a local database. If
Initiator does not know the Responder's HIT, it may attempt the Initiator does not know the Responder's HIT, it may attempt
opportunistic mode by using NULL (all zeros) as the Responder's opportunistic mode by using NULL (all zeros) as the Responder's
HIT. See also "HIP Opportunistic Mode" (Section 4.1.8). If the HIT (see also "HIP Opportunistic Mode" (Section 4.1.8)). If the
Initiator can choose from multiple Responder HITs, it selects a Initiator can choose from multiple Responder HITs, it selects a
HIT for which the Initiator supports the HIT Suite. HIT for which the Initiator supports the HIT Suite.
2. The Initiator sends an I1 to one of the Responder's addresses. 2. The Initiator sends an I1 packet to one of the Responder's
The selection of which address to use is a local policy decision. addresses. The selection of which address to use is a local
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, the sender transitions to state I1-SENT, 4. Upon sending an I1 packet, the sender transitions to state I1-
starts a timer whose timeout value SHOULD be larger than the SENT, starts a timer for which the timeout value SHOULD be larger
worst-case anticipated RTT, and SHOULD increment a timeout than the worst-case anticipated RTT. The sender SHOULD also
counter associated with the I1. increment the timeout counter associated with the I1.
5. Upon timeout, the sender SHOULD retransmit the I1 and restart the 5. Upon timeout, the sender SHOULD retransmit the I1 packet and
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 I1s 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 session establishment latency, an
implementation MAY send the same I1 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) 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 timeout, it MUST NOT send the I1 packet to more than connection after a timeout, it MUST NOT send the I1 packet to more
one destination address. These limitations are placed in order to than one destination address. These limitations are placed in order
avoid congestion of the network, and potential DoS attacks that might to avoid congestion of the network, and potential DoS attacks that
happen, e.g., because someone's claim to have hundreds or thousands might occur, e.g., because someone's claim to have hundreds or
of addresses could generate a huge number of I1 messages from the thousands of addresses could generate a huge number of I1 packets
Initiator. from the Initiator.
As the Responder is not guaranteed to distinguish the duplicate I1s As the Responder is not guaranteed to distinguish the duplicate I1
it receives at several of its addresses (because it avoids storing packets it receives at several of its addresses (because it avoids
states when it answers back an R1), the Initiator may receive several storing states when it answers back an R1 packet), the Initiator may
duplicate R1s. receive several duplicate R1 packets.
The Initiator SHOULD then select the initial preferred destination The Initiator SHOULD then select the initial preferred destination
address using the source address of the selected received R1, and use address using the source address of the selected received R1, and use
the preferred address as a source address for the I2. Processing the preferred address as a source address for the I2 packet.
rules for received R1s are discussed in Section 6.8. Processing rules for received R1s are discussed in Section 6.8.
6.6.2. Processing Incoming ICMP Protocol Unreachable Messages 6.6.2. Processing Incoming ICMP Protocol Unreachable Messages
A host may receive an ICMP 'Destination Protocol Unreachable' message A host may receive an ICMP 'Destination Protocol Unreachable' message
as a response to sending a HIP I1 packet. Such a packet may be an as a response to sending a HIP I1 packet. Such a packet may be an
indication that the peer does not support HIP, or it may be an indication that the peer does not support HIP, or it may be an
attempt to launch an attack by making the Initiator believe that the attempt to launch an attack by making the Initiator believe that the
Responder does not support HIP. Responder does not support HIP.
When a system receives an ICMP 'Destination Protocol Unreachable' When a system receives an ICMP 'Destination Protocol Unreachable'
message while it is waiting for an R1, it MUST NOT terminate the message while it is waiting for an R1 packet, it MUST NOT terminate
wait. It MAY continue as if it had not received the ICMP message, the wait. It MAY continue as if it had not received the ICMP
and send a few more I1s. Alternatively, it MAY take the ICMP message message, and send a few more I1 packets. Alternatively, it MAY take
as a hint that the peer most probably does not support HIP, and the ICMP message as a hint that the peer most probably does not
return to state UNASSOCIATED earlier than otherwise. However, at support HIP, and return to state UNASSOCIATED earlier than otherwise.
minimum, it MUST continue waiting for an R1 for a reasonable time However, at minimum, it MUST continue waiting for an R1 packet for a
before returning to UNASSOCIATED. reasonable time before returning to UNASSOCIATED.
6.7. Processing Incoming I1 Packets 6.7. Processing Incoming I1 Packets
An implementation SHOULD reply to an I1 with an R1 packet, unless the An implementation SHOULD reply to an I1 with an R1 packet, unless the
implementation is unable or unwilling to set up a HIP association. implementation is unable or unwilling to set up a HIP association.
If the implementation is unable to set up a HIP association, the host If the implementation is unable to set up a HIP association, the host
SHOULD send an ICMP Destination Protocol Unreachable, SHOULD send an ICMP Destination Protocol Unreachable,
Administratively Prohibited, message to the I1 source address. If Administratively Prohibited, message to the I1 packet source IP
the implementation is unwilling to set up a HIP association, the host address. If the implementation is unwilling to set up a HIP
MAY ignore the I1. This latter case may occur during a DoS attack association, the host MAY ignore the I1 packet. This latter case may
such as an I1 flood. occur during a DoS attack such as an I1 packet flood.
The implementation MUST be able to handle a storm of received I1 The implementation SHOULD be able to handle a storm of received I1
packets, discarding those with common content that arrive within a packets, discarding those with common content that arrive within a
small time delta. small time delta.
A spoofed I1 can result in an R1 attack on a system. An R1 sender A spoofed I1 packet can result in an R1 attack on a system. An R1
MUST have a mechanism to rate-limit R1s to an address. packet sender MUST have a mechanism to rate-limit R1 packets sent to
an address.
It is RECOMMENDED that the HIP state machine does not transition upon It is RECOMMENDED that the HIP state machine does not transition upon
sending an R1. sending an R1 packet.
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
responding to an I1 packet: responding to an I1 packet:
1. The Responder MUST check that the Responder's HIT in the received 1. The Responder MUST check that the Responder's HIT in the received
I1 is either one of its own HITs or NULL. I1 packet is either one of its own HITs or NULL. Otherwise it
must drop the packet.
2. If the Responder is in ESTABLISHED state, the Responder MAY 2. If the Responder is in ESTABLISHED state, the Responder MAY
respond to this with an R1 packet, prepare to drop existing SAs, respond to this with an R1 packet, prepare to drop existing SAs,
and stay at ESTABLISHED state. and stay at ESTABLISHED state.
3. If the Responder is in I1-SENT state, it must make a comparison 3. If the Responder is in I1-SENT state, it must make a comparison
between the sender's HIT and its own (i.e., the receiver's) HIT. between the sender's HIT and its own (i.e., the receiver's) HIT.
If the sender's HIT is greater than its own HIT, it should drop If the sender's HIT is greater than its own HIT, it should drop
the I1 and stay at I1-SENT. If the sender's HIT is smaller than the I1 packet and stay at I1-SENT. If the sender's HIT is
its own HIT, it should send R1 and stay at I1-SENT. The HIT smaller than its own HIT, it should send the R1 packet and stay
comparison goes similarly as in Section 6.5. at I1-SENT. The HIT comparison is performed as defined in
Section 6.5.
4. If the implementation chooses to respond to the I1 with an R1 4. If the implementation chooses to respond to the I1 packet with an
packet, it creates a new R1 or selects a precomputed R1 according R1 packet, it creates a new R1 or selects a precomputed R1
to the format described in Section 5.3.2. It creates or chooses according to the format described in Section 5.3.2. It creates
an R1 that contains its most preferred DH public value that is or chooses an R1 that contains its most preferred DH public value
also contained in the DH_GROUP_LIST in the I1 packet. If no that is also contained in the DH_GROUP_LIST in the I1 packet. If
suitable DH Group ID was contained in the DH_GROUP_LIST in the I1 no suitable DH Group ID was contained in the DH_GROUP_LIST in the
packet, it sends an R1 with an arbitrary DH public key. I1 packet, it sends an R1 with any suitable DH public key.
5. The R1 MUST contain the received Responder's HIT, unless the 5. If the received Responder's HIT in the I1 is NULL, the Responder
received HIT is NULL, in which case the Responder SHOULD select a a HIT with a the same HIT Suite as the Initiator's HIT. If this
HIT that is constructed with the MUST algorithm in Section 3, HIT Suite is not supported by the Responder, it SHOULD select a
which is currently RSA. Other than that, selecting the HIT is a REQUIRED HIT Suite from Section 5.2.9, which is currently RSA/
local policy matter. DSA/SHA-1. Other than that, selecting the HIT is a local policy
matter.
6. The Responder sends the R1 to the source IP address of the I1 6. The Responder sends the R1 packet to the source IP address of the
packet. I1 packet.
6.7.1. R1 Management 6.7.1. R1 Management
All compliant implementations MUST produce R1 packets. An R1 packet All compliant implementations MUST produce R1 packets. An R1 packet
MAY be precomputed. An R1 packet MAY be reused for time Delta T, MAY be precomputed. An R1 packet MAY be reused for time Delta T,
which is implementation dependent, and SHOULD be deprecated and not which is implementation dependent, and SHOULD be deprecated and not
used once a valid response I2 packet has been received from an used once a valid response I2 packet has been received from an
Initiator. During an I1 message storm, an R1 packet may be re-used Initiator. During an I1 message storm, an R1 packet may be re-used
beyond this limit. R1 information MUST NOT be discarded until Delta beyond this limit. R1 information MUST NOT be discarded until Delta
S after T. Time S is the delay needed for the last I2 to arrive back S after T. Time S is the delay needed for the last I2 packet to
to the Responder. arrive back to the Responder.
Implementations that support multiple DH groups MAY pre-compute R1 Implementations that support multiple DH groups MAY pre-compute R1
packets for each supported group so that incoming I1 packets with packets for each supported group so that incoming I1 packets with
different DH Group IDs in the DH_GROUP_LIST can be served quickly. different DH Group IDs in the DH_GROUP_LIST can be served quickly.
An implementation MAY keep state about received I1s and match the An implementation MAY keep state about received I1 packets and match
received I2s against the state, as discussed in Section 4.1.1. the received I2 packets against the state, as discussed in
Section 4.1.1.
6.7.2. Handling Malformed Messages 6.7.2. Handling Malformed Messages
If an implementation receives a malformed I1 message, it SHOULD NOT If an implementation receives a malformed I1 packet, it SHOULD NOT
respond with a NOTIFY message, as such practice could open up a respond with a NOTIFY message, as such practice could open up a
potential denial-of-service danger. Instead, it MAY respond with an potential denial-of-service danger. Instead, it MAY respond with an
ICMP packet, as defined in Section 5.4. ICMP packet, as defined in Section 5.4.
6.8. Processing Incoming R1 Packets 6.8. Processing Incoming R1 Packets
A system receiving an R1 MUST first check to see if it has sent an I1 A system receiving an R1 packet MUST first check to see if it has
to the originator of the R1 (i.e., it is in state I1-SENT). If so, sent an I1 packet to the originator of the R1 packet (i.e., it is in
it SHOULD process the R1 as described below, send an I2, and go to state I1-SENT). If so, it SHOULD process the R1 as described below,
state I2-SENT, setting a timer to protect the I2. If the system is send an I2 packet, and transition to state I2-SENT, setting a timer
in state I2-SENT, it MAY respond to an R1 if the R1 has a larger R1 to protect the I2 packet. If the system is in state I2-SENT, it MAY
generation counter; if so, it should drop its state due to processing respond to the R1 packet if the R1 packet has a larger R1 generation
the previous R1 and start over from state I1-SENT. If the system is counter; if so, it should drop its state due to processing the
in any other state with respect to that host, it SHOULD silently drop previous R1 packet and start over from state I1-SENT. If the system
the R1. is in any other state with respect to that host, the system SHOULD
silently drop the R1 packet.
When sending multiple I1s, an Initiator SHOULD wait for a small When sending multiple I1 packets, an Initiator SHOULD wait for a
amount of time after the first R1 reception to allow possibly small amount of time after the first R1 reception to allow possibly
multiple R1s to arrive, and it SHOULD respond to an R1 among the set multiple R1 packets to arrive, and it SHOULD respond to an R1 packet
with the largest R1 generation counter. among the set with the largest R1 generation counter.
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
responding to an R1 packet: responding to an R1 packet:
1. A system receiving an R1 MUST first check to see if it has sent 1. A system receiving an R1 MUST first check to see if it has sent
an I1 to the originator of the R1 (i.e., it has a HIP an I1 packet to the originator of the R1 packet (i.e., it has a
association that is in state I1-SENT and that is associated with HIP association that is in state I1-SENT and that is associated
the HITs in the R1). Unless the I1 was sent in opportunistic with the HITs in the R1). Unless the I1 packet was sent in
mode (see Section 4.1.8), the IP addresses in the received R1 opportunistic mode (see Section 4.1.8), the IP addresses in the
packet SHOULD be ignored and, when looking up the right HIP received R1 packet SHOULD be ignored and, when looking up the
association, the received R1 SHOULD be matched against the right HIP association, the received R1 packet SHOULD be matched
associations using only the HITs. If a match exists, the system against the associations using only the HITs. If a match
should process the R1 as described below. exists, the system should process the R1 packet as described
below.
2. Otherwise, if the system is in any other state than I1-SENT or 2. Otherwise, if the system is in any other state than I1-SENT or
I2-SENT with respect to the HITs included in the R1, it SHOULD I2-SENT with respect to the HITs included in the R1 packet, it
silently drop the R1 and remain in the current state. SHOULD silently drop the R1 packet and remain in the current
state.
3. If the HIP association state is I1-SENT or I2-SENT, the received 3. If the HIP association state is I1-SENT or I2-SENT, the received
Initiator's HIT MUST correspond to the HIT used in the original, Initiator's HIT MUST correspond to the HIT used in the original
and the I1 and the Responder's HIT MUST correspond to the one I1. Also, the Responder's HIT MUST correspond to the one used
used, unless the I1 contained a NULL HIT. in the I1, unless the I1 packet contained a NULL HIT.
4. The system SHOULD validate the R1 signature before applying 4. The system SHOULD validate the R1 signature before applying
further packet processing, according to Section 5.2.14. further packet processing, according to Section 5.2.14.
5. If the HIP association state is I1-SENT, and multiple valid R1s 5. If the HIP association state is I1-SENT, and multiple valid R1
are present, the system MUST select from among the R1s with the packets are present, the system MUST select from among the R1
largest R1 generation counter. packets with the largest R1 generation counter.
6. The system MUST check that the Initiator HIT Suite is contained 6. The system MUST check that the Initiator HIT Suite is contained
in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the
Initiator's HIT Suite is supported by the Responder). If the Initiator's HIT Suite is supported by the Responder). If the
HIT Suite is supported by the Responder, the system proceeds HIT Suite is supported by the Responder, the system proceeds
normally. Otherwise, the system MAY stay in state I1-sent and normally. Otherwise, the system MAY stay in state I1-sent and
restart the BEX by sending a new I1 packet with a Initiator HIT restart the BEX by sending a new I1 packet with a Initiator HIT
that is supported by the Responder and hence is contained in the that is supported by the Responder and hence is contained in the
HIT_SUITE_LIST in the R1 packet. The system MAY abort the BEX HIT_SUITE_LIST in the R1 packet. The system MAY abort the BEX
if no suitable source HIT is available. The system SHOULD wait if no suitable source HIT is available. The system SHOULD wait
for acceptable time span to allow further R1 packets with higher for an acceptable time span to allow further R1 packets with
R1 generation counters to arrive before restarting or aborting higher R1 generation counters or different HIT and HIT Suites to
the BEX. arrive before restarting or aborting the BEX.
7. The system MUST check that the DH Group ID in the DH parameter 7. The system MUST check that the DH Group ID in the DH parameter
in the R1 matches the first DH Suite ID in the Responder's in the R1 matches the first DH Suite ID in the Responder's
DH_GROUP_LIST in the R1 that was also contained in the DH_GROUP_LIST in the R1 packet that was also contained in the
Initiator's DH_GROUP_LIST in the I1. If the two DH Group ID of Initiator's DH_GROUP_LIST in the I1 packet. If the DH Group ID
the DH parameter does not express the Responder's best choice, of the DH parameter does not express the Responder's best
the Initiator can conclude that the DH_GROUP_LIST in the I1 was choice, the Initiator can conclude that the DH_GROUP_LIST in the
adversely modified. In such case, the Initiator MAY send a new I1 packet was adversely modified. In such case, the Initiator
I1 packet, however, it SHOULD not change its preference in the MAY send a new I1 packet, however, it SHOULD not change its
DH_GROUP_LIST in the new I1. Alternatively, the Initiator MAY preference in the DH_GROUP_LIST in the new I1 packet.
abort the HIP exchange. Alternatively, the Initiator MAY abort the HIP exchange.
8. If the HIP association state is I2-SENT, the system MAY reenter 8. If the HIP association state is I2-SENT, the system MAY re-enter
state I1-SENT and process the received R1 if it has a larger R1 state I1-SENT and process the received R1 packet if it has a
generation counter than the R1 responded to previously. larger R1 generation counter than the R1 packet responded to
previously.
9. The R1 packet may have the A bit set -- in this case, the system 9. The R1 packet may have the A bit set -- in this case, the system
MAY choose to refuse it by dropping the R1 and returning to MAY choose to refuse it by dropping the R1 packet and returning
state UNASSOCIATED. The system SHOULD consider dropping the R1 to state UNASSOCIATED. The system SHOULD consider dropping the
only if it used a NULL HIT in I1. If the A bit is set, the R1 packet only if it used a NULL HIT in I1 packet. If the A bit
Responder's HIT is anonymous and should not be stored. is set, the Responder's HIT is anonymous and should not be
stored permanently.
10. The system SHOULD attempt to validate the HIT against the 10. The system SHOULD attempt to validate the HIT against the
received Host Identity by using the received Host Identity to received Host Identity by using the received Host Identity to
construct a HIT and verify that it matches the Sender's HIT. construct a HIT and verify that it matches the Sender's HIT.
11. The system MUST store the received R1 generation counter for 11. The system MUST store the received R1 generation counter for
future reference. future reference.
12. The system attempts to solve the puzzle in R1. The system MUST 12. The system attempts to solve the puzzle in the R1 packet. The
terminate the search after exceeding the remaining lifetime of system MUST terminate the search after exceeding the remaining
the puzzle. If the puzzle is not successfully solved, the lifetime of the puzzle. If the puzzle is not successfully
implementation may either resend I1 within the retry bounds or solved, the implementation may either resend the I1 packet
abandon the HIP exchange. within the retry bounds or abandon the HIP exchange.
13. The system computes standard Diffie-Hellman keying material 13. The system computes standard Diffie-Hellman keying material
according to the public value and Group ID provided in the according to the public value and Group ID provided in the
DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material
Kij is used for key extraction as specified in Section 6.5. If Kij is used for key extraction as specified in Section 6.5.
the received Diffie-Hellman Group ID is not supported, the
implementation may either resend I1 within the retry bounds or
abandon the HIP exchange.
14. The system selects the HIP_CIPHER ID from the choices presented 14. The system selects the HIP_CIPHER ID from the choices presented
in the R1 packet and uses the selected values subsequently when in the R1 packet and uses the selected values subsequently when
generating and using encryption keys, and when sending the I2. generating and using encryption keys, and when sending the I2
If the proposed alternatives are not acceptable to the system, packet. If the proposed alternatives are not acceptable to the
it may either resend I1 within the retry bounds or abandon the system, it may either resend an I1 within the retry bounds or
HIP exchange. abandon the HIP exchange.
15. The system initializes the remaining variables in the associated 15. The system initializes the remaining variables in the associated
state, including Update ID counters. state, including Update ID counters.
16. The system prepares and sends an I2, as described in 16. The system prepares and sends an I2 packet, as described in
Section 5.3.3. Section 5.3.3.
17. The system SHOULD start a timer whose timeout value should be 17. The system SHOULD start a timer whose timeout value should be
larger than the worst-case anticipated RTT, and MUST increment a larger than the worst-case anticipated RTT, and MUST increment a
timeout counter associated with the I2. The sender SHOULD timeout counter associated with the I2 packet. The sender
retransmit the I2 upon a timeout and restart the timer, up to a SHOULD retransmit the I2 packet upon a timeout and restart the
maximum of I2_RETRIES_MAX tries. timer, up to a maximum of I2_RETRIES_MAX tries.
18. If the system is in state I1-SENT, it shall transition to state 18. 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 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 typically doesn't have any state. An as the sender of the R1 packet typically doesn't have any state. An
implementation SHOULD wait for some more time for a possibly good R1, implementation SHOULD wait for some more time for a possibly well-
after which it MAY try again by sending a new I1 packet. formed R1, after which it MAY try again by sending a new I1 packet.
6.9. Processing Incoming I2 Packets 6.9. Processing Incoming I2 Packets
Upon receipt of an I2, the system MAY perform initial checks to Upon receipt of an I2 packet, the system MAY perform initial checks
determine whether the I2 corresponds to a recent R1 that has been to determine whether the I2 packet corresponds to a recent R1 packet
sent out, if the Responder keeps such state. For example, the sender that has been sent out, if the Responder keeps such state. For
could check whether the I2 is from an address or HIT that has example, the sender could check whether the I2 packet is from an
recently received an R1 from it. The R1 may have had Opaque data address or HIT for which the Responder has recently received an I1.
included that was echoed back in the I2. If the I2 is considered to The R1 packet may have had Opaque data included that was echoed back
be suspect, it MAY be silently discarded by the system. in the I2 packet. If the I2 packet is considered to be suspect, it
MAY be silently discarded by the system.
Otherwise, the HIP implementation SHOULD process the I2. This Otherwise, the HIP implementation SHOULD process the I2 packet. This
includes validation of the puzzle solution, generating the Diffie- includes validation of the puzzle solution, generating the Diffie-
Hellman key, decrypting the Initiator's Host Identity, verifying the Hellman key, decrypting the Initiator's Host Identity, verifying the
signature, creating state, and finally sending an R2. signature, creating state, and finally sending an R2 packet.
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
responding to an I2 packet: responding to an I2 packet:
1. The system MAY perform checks to verify that the I2 corresponds 1. The system MAY perform checks to verify that the I2 packet
to a recently sent R1. Such checks are implementation corresponds to a recently sent R1 packet. Such checks are
dependent. See Appendix A for a description of an example implementation dependent. See Appendix A for a description of
implementation. an example implementation.
2. The system MUST check that the Responder's HIT corresponds to 2. The system MUST check that the Responder's HIT corresponds to
one of its own HITs. one of its own HITs and MUST drop the packet otherwise.
3. The system MUST further check that the Initiator's HIT Suite is 3. The system MUST further check that the Initiator's HIT Suite is
supported. The Responder SHOULD drop I2 packets with supported. The Responder SHOULD silently drop I2 packets with
unsupported Initiator HITs silently. unsupported Initiator HITs.
4. If the system's state machine is in the R2-SENT state, the 4. If the system's state machine is in the R2-SENT state, the
system MAY check if the newly received I2 is similar to the one system MAY check if the newly received I2 packet is similar to
that triggered moving to R2-SENT. If so, it MAY retransmit a the one that triggered moving to R2-SENT. If so, it MAY
previously sent R2, reset the R2-SENT timer, and the state retransmit a previously sent R2 packet, reset the R2-SENT timer,
machine stays in R2-SENT. and the state machine stays in R2-SENT.
5. If the system's state machine is in the I2-SENT state, the 5. If the system's state machine is in the I2-SENT state, the
system makes a comparison between its local and sender's HITs system makes a comparison between its local and sender's HITs
(similarly as in Section 6.5). If the local HIT is smaller than (similarly as in Section 6.5). If the local HIT is smaller than
the sender's HIT, it should drop the I2 packet, use the peer the sender's HIT, it should drop the I2 packet, use the peer
Diffie-Hellman key and nonce I from the R1 packet received Diffie-Hellman key and nonce I from the R1 packet received
earlier, and get the local Diffie-Hellman key and nonce J from earlier, and get the local Diffie-Hellman key and nonce J from
the I2 packet sent to the peer earlier. Otherwise, the system the I2 packet sent to the peer earlier. Otherwise, the system
should process the received I2 packet and drop any previously should process the received I2 packet and drop any previously
derived Diffie-Hellman keying material Kij it might have formed derived Diffie-Hellman keying material Kij it might have formed
upon sending the I2 previously. The peer Diffie-Hellman key and upon sending the I2 packet previously. The peer Diffie-Hellman
the nonce J are taken from the just arrived I2 packet. The key and the nonce J are taken from the just arrived I2 packet.
local Diffie-Hellman key and the nonce I are the ones that were The local Diffie-Hellman key and the nonce I are the ones that
earlier sent 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 match those used in the previously sent I1, the HITs in the I2 packet match those used in the previously sent I1
system uses this received I2 as the basis for the HIP packet, the system uses this received I2 packet as the basis for
association it was trying to form, and stops retransmitting I1 the HIP association it was trying to form, and stops
(provided that the I2 passes the below additional checks). retransmitting I1 packets (provided that the I2 packet passes
the below additional checks).
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 R2-
SENT, the system SHOULD check that the echoed R1 generation SENT, the system SHOULD check that the echoed R1 generation
counter in I2 is within the acceptable range. Implementations counter in the I2 packet is within the acceptable range.
MUST accept puzzles from the current generation and MAY accept Implementations MUST accept puzzles from the current generation
puzzles from earlier generations. If the newly received I2 is and MAY accept puzzles from earlier generations. If the
outside the accepted range, the I2 is stale (perhaps replayed) generation counter in the newly received I2 packet is outside
and SHOULD be dropped. the accepted range, the I2 packet is stale (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.
9. The I2 MUST have a single value in the HIP_CIPHER parameter, 9. The I2 packet MUST have a single value in the HIP_CIPHER
which MUST match one of the values offered to the Initiator in parameter, which MUST match one of the values offered to the
the R1 packet. Initiator in the R1 packet.
10. The system must derive Diffie-Hellman keying material Kij based 10. The system must derive Diffie-Hellman keying material Kij based
on the public value and Group ID in the DIFFIE_HELLMAN on the public value and Group ID in the DIFFIE_HELLMAN
parameter. This key is used to derive the HIP association keys, parameter. This key is used to derive the HIP association keys,
as described in Section 6.5. If the Diffie-Hellman Group ID is as described in Section 6.5. If the Diffie-Hellman Group ID is
unsupported, the I2 packet is silently dropped. unsupported, the I2 packet is silently dropped.
11. The encrypted HOST_ID is decrypted by the Initiator encryption 11. The encrypted HOST_ID is decrypted by the Initiator's encryption
key defined in Section 6.5. If the decrypted data is not a key defined in Section 6.5. If the decrypted data is not a
HOST_ID parameter, the I2 packet is silently dropped. HOST_ID parameter, the I2 packet is silently dropped.
12. The implementation SHOULD also verify that the Initiator's HIT 12. The implementation SHOULD also verify that the Initiator's HIT
in the I2 corresponds to the Host Identity sent in the I2. in the I2 packet corresponds to the Host Identity sent in the
(Note: some middleboxes may not able to make this verification.) packet I2. (Note: some middleboxes may not able to make this
verification.)
13. The system MUST verify the HMAC according to the procedures in 13. The system MUST verify the HMAC according to the procedures in
Section 5.2.11. Section 5.2.11.
14. The system MUST verify the HIP_SIGNATURE according to 14. The system MUST verify the HIP_SIGNATURE according to
Section 5.2.13 and Section 5.3.3. Section 5.2.13 and Section 5.3.3.
15. If the checks above are valid, then the system proceeds with 15. If the checks above are valid, then the system proceeds with
further I2 processing; otherwise, it discards the I2 and its further I2 processing; otherwise, it discards the I2 and its
state machine remains in the same state. state machine remains in the same state.
16. The I2 packet may have the A bit set -- in this case, the system 16. The I2 packet may have the A bit set -- in this case, the system
MAY choose to refuse it by dropping the I2 and the state machine MAY choose to refuse it by dropping the I2 and the state machine
returns to state UNASSOCIATED. If the A bit is set, the returns to state UNASSOCIATED. If the A bit is set, the
Initiator's HIT is anonymous and should not be stored. Initiator's HIT is anonymous and should not be stored
permanently.
17. The system initializes the remaining variables in the associated 17. The system initializes the remaining variables in the associated
state, including Update ID counters. state, including Update ID counters.
18. Upon successful processing of an I2 when the system's state 18. Upon successful processing of an I2 message when the system's
machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2-SENT, state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2-
an R2 is sent and the system's state machine transitions to SENT, an R2 packet is sent and the system's state machine
state R2-SENT. transitions to state R2-SENT.
19. Upon successful processing of an I2 when the system's state 19. Upon successful processing of an I2 packet when the system's
machine is in state ESTABLISHED, the old HIP association is state machine is in state ESTABLISHED, the old HIP association
dropped and a new one is installed, an R2 is sent, and the is dropped and a new one is installed, an R2 packet is sent, and
system's state machine transitions to R2-SENT. the system's state machine transitions to R2-SENT.
20. Upon the system's state machine transitioning to R2-SENT, the 20. 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
association, or an UPDATE packet has been received (or some association, or an UPDATE packet has been received (or some
other packet that indicates that the peer system's state machine other packet that indicates that the peer system's state machine
has moved to ESTABLISHED). If the timer expires (allowing for has moved to ESTABLISHED). If the timer expires (allowing for
maximal retransmissions of I2s), the state machine transitions maximal retransmissions of I2 packets), the state machine
to ESTABLISHED. transitions to ESTABLISHED.
6.9.1. Handling Malformed Messages 6.9.1. Handling of Malformed Messages
If an implementation receives a malformed I2 message, the behavior If an implementation receives a malformed I2 message, the behavior
SHOULD depend on how many checks the message has already passed. If SHOULD depend on how many checks the message has already passed. If
the puzzle solution in the message has already been checked, the the puzzle solution in the message has already been checked, the
implementation SHOULD report the error by responding with a NOTIFY implementation SHOULD report the error by responding with a NOTIFY
packet. Otherwise, the implementation MAY respond with an ICMP packet. Otherwise, the implementation MAY respond with an ICMP
message as defined in Section 5.4. message as defined in Section 5.4.
6.10. Processing Incoming R2 Packets 6.10. Processing of Incoming R2 Packets
An R2 received in states UNASSOCIATED, I1-SENT, or ESTABLISHED An R2 packet received in states UNASSOCIATED, I1-SENT, or ESTABLISHED
results in the R2 being dropped and the state machine staying in the results in the R2 packet being dropped and the state machine staying
same state. If an R2 is received in state I2-SENT, it SHOULD be in the same state. If an R2 packet is received in state I2-SENT, it
processed. SHOULD be processed.
The following steps define the conceptual processing rules for an The following steps define the conceptual processing rules for an
incoming R2 packet: incoming R2 packet:
1. The system MUST verify that the HITs in use correspond to the 1. If the system is in any other state than I2-SENT, the R2 packet
HITs that were received in the R1. is silently dropped.
2. The system MUST verify the HIP_MAC_2 according to the procedures 2. The system MUST verify that the HITs in use correspond to the
HITs that were received in the R1 packet.
3. The system MUST verify the HIP_MAC_2 according to the procedures
in Section 5.2.12. in Section 5.2.12.
3. The system MUST verify the HIP signature according to the 4. The system MUST verify the HIP signature according to the
procedures in Section 5.2.13. procedures in Section 5.2.13.
4. If any of the checks above fail, there is a high probability of 5. If any of the checks above fail, there is a high probability of
an ongoing man-in-the-middle or other security attack. The an ongoing man-in-the-middle or other security attack. The
system SHOULD act accordingly, based on its local policy. system SHOULD act accordingly, based on its local policy.
5. If the system is in any other state than I2-SENT, the R2 is 6. Upon successful processing of the R2 packet, the state machine
silently dropped. transitions to state ESTABLISHED.
6. Upon successful processing of the R2, the state machine moves to
state ESTABLISHED.
6.11. Sending UPDATE Packets 6.11. Sending UPDATE Packets
A host sends an UPDATE packet when it wants to update some A host sends an UPDATE packet when it intends to update some
information related to a HIP association. There are a number of information related to a HIP association. There are a number of
likely situations, e.g., mobility management and rekeying of an possible scenarios when this can occur, e.g., mobility management and
existing ESP Security Association. The following paragraphs define rekeying of an existing ESP Security Association. The following
the conceptual rules for sending an UPDATE packet to the peer. paragraphs define the conceptual rules for sending an UPDATE packet
Additional steps can be defined in other documents where the UPDATE to the peer. Additional steps can be defined in other documents
packet is used. where the UPDATE packet is used.
The system first determines whether there are any outstanding UPDATE The sequence of UPDATE messages is indicated by their SEQ parameter.
messages that may conflict with the new UPDATE message under Before sending an UPDATE message, the system first determines whether
consideration. When multiple UPDATEs are outstanding (not yet there are any outstanding UPDATE messages that may conflict with the
acknowledged), the sender must assume that such UPDATEs may be new UPDATE message under consideration. When multiple UPDATEs are
processed in an arbitrary order. Therefore, any new UPDATEs that outstanding (not yet acknowledged), the sender must assume that such
depend on a previous outstanding UPDATE being successfully received UPDATEs may be processed in an arbitrary order by the receiver.
and acknowledged MUST be postponed until reception of the necessary Therefore, any new UPDATEs that depend on a previous outstanding
ACK(s) occurs. One way to prevent any conflicts is to only allow one UPDATE being successfully received and acknowledged MUST be postponed
outstanding UPDATE at a time. However, allowing multiple UPDATEs may until reception of the necessary ACK(s) occurs. One way to prevent
improve the performance of mobility and multihoming protocols. any conflicts is to only allow one outstanding UPDATE at a time.
However, allowing multiple UPDATEs may improve the performance of
mobility and multihoming protocols.
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
sending UPDATE packets. sending UPDATE packets.
1. The first UPDATE packet is sent with Update ID of zero. 1. The first UPDATE packet is sent with Update ID of zero.
Otherwise, the system increments its own Update ID value by one Otherwise, the system increments its own Update ID value by one
before continuing the below steps. before continuing the steps below .
2. The system creates an UPDATE packet that contains a SEQ parameter 2. The system creates an UPDATE packet that contains a SEQ parameter
with the current value of Update ID. The UPDATE packet may also with the current value of Update ID. The UPDATE packet MAY also
include an ACK of the peer's Update ID found in a received UPDATE include an ACK of the peer's Update ID found in a received UPDATE
SEQ parameter, if any. SEQ parameter, if any.
3. The system sends the created UPDATE packet and starts an UPDATE 3. The system sends the created UPDATE packet and starts an UPDATE
timer. The default value for the timer is 2 * RTT estimate. If timer. The default value for the timer is 2 * RTT estimate. If
multiple UPDATEs are outstanding, multiple timers are in effect. multiple UPDATEs are outstanding, multiple timers are in effect.
4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE
can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be
exponentially backed off for subsequent retransmissions. If no exponentially backed off for subsequent retransmissions. If no
skipping to change at page 95, line 23 skipping to change at page 96, line 41
receiving an ACK from the peer that acknowledges receipt of the receiving an ACK from the peer that acknowledges receipt of the
UPDATE. UPDATE.
6.12. Receiving UPDATE Packets 6.12. Receiving UPDATE Packets
When a system receives an UPDATE packet, its processing depends on When a system receives an UPDATE packet, its processing depends on
the state of the HIP association and the presence and values of the the state of the HIP association and the presence and values of the
SEQ and ACK parameters. Typically, an UPDATE message also carries SEQ and ACK parameters. Typically, an UPDATE message also carries
optional parameters whose handling is defined in separate documents. optional parameters whose handling is defined in separate documents.
For each association, the peer's next expected in-sequence Update ID For each association, a host stores the peer's next expected in-
("peer Update ID") is stored. Initially, this value is zero. Update sequence Update ID ("peer Update ID"). Initially, this value is
ID comparisons of "less than" and "greater than" are performed with zero. Update ID comparisons of "less than" and "greater than" are
respect to a circular sequence number space. performed with respect to a circular sequence number space. Hence, a
wrap around after 2^32 updates has to be expected and must be handled
accordingly.
The sender may send multiple outstanding UPDATE messages. These The sender may send multiple outstanding UPDATE messages. These
messages are processed in the order in which they are received at the messages are processed in the order in which they are received at the
receiver (i.e., no re-sequencing is performed). When processing receiver (i.e., no re-sequencing is performed). When processing
UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs
were previously processed, so that duplicates or retransmissions are were previously processed, so that duplicates or retransmissions are
ACKed and not reprocessed. A receiver MAY choose to define a receive ACKed and not reprocessed. A receiver MAY choose to define a receive
window of Update IDs that it is willing to process at any given time, window of Update IDs that it is willing to process at any given time,
and discard received UPDATEs falling outside of that window. and discard received UPDATEs falling outside of that window.
skipping to change at page 96, line 23 skipping to change at page 97, line 42
handling a SEQ parameter in a received UPDATE packet. handling a SEQ parameter in a received UPDATE packet.
1. If the Update ID in the received SEQ is not the next in the 1. If the Update ID in the received SEQ is not the next in the
sequence of Update IDs and is greater than the receiver's window sequence of Update IDs and is greater than the receiver's window
for new UPDATEs, the packet MUST be dropped. for new UPDATEs, the packet MUST be dropped.
2. If the Update ID in the received SEQ corresponds to an UPDATE 2. If the Update ID in the received SEQ corresponds to an UPDATE
that has recently been processed, the packet is treated as a that has recently been processed, the packet is treated as a
retransmission. The HIP_MAC verification (next step) MUST NOT be retransmission. The HIP_MAC verification (next step) MUST NOT be
skipped. (A byte-by-byte comparison of the received and a stored skipped. (A byte-by-byte comparison of the received and a stored
packet would be OK, though.) It is recommended that a host cache packet would be acceptable, though.) It is recommended that a
UPDATE packets sent with ACKs to avoid the cost of generating a host caches UPDATE packets sent with ACKs to avoid the cost of
new ACK packet to respond to a replayed UPDATE. The system MUST generating a new ACK packet to respond to a replayed UPDATE. The
acknowledge, again, such (apparent) UPDATE message system MUST acknowledge, again, such (apparent) UPDATE message
retransmissions but SHOULD also consider rate-limiting such retransmissions but SHOULD also consider rate-limiting such
retransmission responses to guard against replay attacks. retransmission responses to guard against replay attacks.
3. The system MUST verify the HIP_MAC in the UPDATE packet. If the 3. The system MUST verify the HIP_MAC in the UPDATE packet. If the
verification fails, the packet MUST be dropped. verification fails, the packet MUST be dropped.
4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the
verification fails, the packet SHOULD be dropped and an error verification fails, the packet SHOULD be dropped and an error
message logged. message logged.
skipping to change at page 97, line 5 skipping to change at page 98, line 24
and sent to the peer. This ACK parameter may be included in a and sent to the peer. This ACK parameter may be included in a
separate UPDATE or piggybacked in an UPDATE with SEQ parameter, separate UPDATE or piggybacked in an UPDATE with SEQ parameter,
as described in Section 5.3.5. The ACK parameter MAY acknowledge as described in Section 5.3.5. The ACK parameter MAY acknowledge
more than one of the peer's Update IDs. more than one of the peer's Update IDs.
6.12.2. Handling an ACK Parameter in a Received UPDATE Packet 6.12.2. Handling an ACK Parameter in a Received UPDATE Packet
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
handling an ACK parameter in a received UPDATE packet. handling an ACK parameter in a received UPDATE packet.
1. The sequence number reported in the ACK must match with an 1. The sequence number reported in the ACK must match with an UPDATE
earlier sent UPDATE packet that has not already been packet sent earlier that has not already been acknowledged. If
acknowledged. If no match is found or if the ACK does not no match is found or if the ACK does not acknowledge a new
acknowledge a new UPDATE, the packet MUST either be dropped if no UPDATE, the packet MUST either be dropped if no SEQ parameter is
SEQ parameter is present, or the processing steps in present, or the processing steps in Section 6.12.1 are followed.
Section 6.12.1 are followed.
2. The system MUST verify the HIP_MAC in the UPDATE packet. If the 2. The system MUST verify the HIP_MAC in the UPDATE packet. If the
verification fails, the packet MUST be dropped. verification fails, the packet MUST be dropped.
3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the
verification fails, the packet SHOULD be dropped and an error verification fails, the packet SHOULD be dropped and an error
message logged. message logged.
4. The corresponding UPDATE timer is stopped (see Section 6.11) so 4. The corresponding UPDATE timer is stopped (see Section 6.11) so
that the now acknowledged UPDATE is no longer retransmitted. If that the now acknowledged UPDATE is no longer retransmitted. If
multiple UPDATEs are newly acknowledged, multiple timers are multiple UPDATEs are newly acknowledged, multiple timers are
stopped. stopped.
6.13. Processing NOTIFY Packets 6.13. Processing of NOTIFY Packets
Processing NOTIFY packets is OPTIONAL. If processed, any errors in a Processing of NOTIFY packets is OPTIONAL. If processed, any errors
received NOTIFICATION parameter SHOULD be logged. Received errors in a received NOTIFICATION parameter SHOULD be logged. Received
MUST be considered only as informational, and the receiver SHOULD NOT errors MUST be considered only as informational, and the receiver
change its HIP state (Section 4.4.2) purely based on the received SHOULD NOT change its HIP state (see Section 4.4.2) purely based on
NOTIFY message. the received NOTIFY message.
6.14. Processing CLOSE Packets 6.14. Processing CLOSE Packets
When the host receives a CLOSE message, it responds with a CLOSE_ACK When the host receives a CLOSE message, it responds with a CLOSE_ACK
message and moves to CLOSED state. (The authenticity of the CLOSE message and moves to CLOSED state. (The authenticity of the CLOSE
message is verified using both HIP_MAC and SIGNATURE). This message is verified using both HIP_MAC and SIGNATURE). This
processing applies whether or not the HIP association state is processing applies whether or not the HIP association state is
CLOSING in order to handle CLOSE messages from both ends that cross CLOSING in order to handle simultaneous CLOSE messages from both ends
in flight. that cross in flight.
The HIP association is not discarded before the host moves from the The HIP association is not discarded before the host moves from the
UNASSOCIATED state. UNASSOCIATED state.
Once the closing process has started, any need to send data packets Once the closing process has started, any new need to send data
will trigger creating and establishing of a new HIP association, packets triggers creating and establishing of a new HIP association,
starting with sending an I1. starting with sending of an I1 packet.
If there is no corresponding HIP association, the CLOSE packet is If there is no corresponding HIP association, the CLOSE packet is
dropped. dropped.
6.15. Processing CLOSE_ACK Packets 6.15. Processing CLOSE_ACK Packets
When a host receives a CLOSE_ACK message, it verifies that it is in When a host receives a CLOSE_ACK message, it verifies that it is in
CLOSING or CLOSED state and that the CLOSE_ACK was in response to the CLOSING or CLOSED state and that the CLOSE_ACK was in response to the
CLOSE (using the included ECHO_RESPONSE_SIGNED in response to the CLOSE. A host can map CLOSE messages to CLOSE_ACK messages by using
sent ECHO_REQUEST_SIGNED). the included ECHO_RESPONSE_SIGNED in response to the sent
ECHO_REQUEST_SIGNED in the CLOSE_ACK.
The CLOSE_ACK uses HIP_MAC and SIGNATURE for verification. The state The CLOSE_ACK contains the HIP_MAC and the SIGNATURE for
is discarded when the state changes to UNASSOCIATED and, after that, verification. The state is discarded when the state changes to
the host MAY respond with an ICMP Parameter Problem to an incoming UNASSOCIATED and, after that, the host MAY respond with an ICMP
CLOSE message (see Section 5.4.4). Parameter Problem to an incoming CLOSE message (see Section 5.4.4).
6.16. Handling State Loss 6.16. Handling State Loss
In the case of system crash and unanticipated state loss, the system In the case of a system crash and unanticipated state loss, the
SHOULD delete the corresponding HIP state, including the keying system SHOULD delete the corresponding HIP state, including the
material. That is, the state SHOULD NOT be stored on stable storage. keying material. That is, the state SHOULD NOT be stored on long-
If the implementation does drop the state (as RECOMMENDED), it MUST term storage. If the implementation does drop the state (as
also drop the peer's R1 generation counter value, unless a local RECOMMENDED), it MUST also drop the peer's R1 generation counter
policy explicitly defines that the value of that particular host is value, unless a local policy explicitly defines that the value of
stored. An implementation MUST NOT store R1 generation counters by that particular host is stored. An implementation MUST NOT store a
default, but storing R1 generation counter values, if done, MUST be peer's R1 generation counters by default, but storing R1 generation
configured by explicit HITs. counter values, if done, MUST be configured by explicit HITs.
7. HIP Policies 7. HIP Policies
There are a number of variables that will influence the HIP exchanges There are a number of variables that will influence the HIP exchanges
that each host must support. All HIP implementations MUST support that each host must support. All HIP implementations MUST support
more than one simultaneous HI, at least one of which SHOULD be more than one simultaneous HI, at least one of which SHOULD be
reserved for anonymous usage. Although anonymous HIs will be rarely reserved for anonymous usage. Although anonymous HIs will be rarely
used as Responders' HIs, they will be common for Initiators. Support used as Responders' HIs, they will be common for Initiators. Support
for more than two HIs is RECOMMENDED. for more than two HIs is RECOMMENDED.
Many Initiators would want to use a different HI for different Initiators may use a different HI for different Responders to provide
Responders. The implementations SHOULD provide for an ACL of basic privacy. Such implementations SHOULD keep state for mapping
Initiator's HIT to Responder's HIT. This ACL SHOULD also include Initiator's HIT to Responder's HIT. This ACL SHOULD also include
preferred transform and local lifetimes. preferred transform and local lifetimes.
The value of K used in the HIP R1 packet can also vary by policy. K The value of K used in the HIP R1 packet can also vary by policy. K
should never be greater than 20, but for trusted partners it could be should never be greater than 20, but for trusted partners it could be
as low as 0. as low as 0.
Responders would need a similar ACL, representing which hosts they Responders that only respond to selected Initiators require an ACL,
accept HIP exchanges, and the preferred transform and local representing which hosts they accept HIP exchanges, and the preferred
lifetimes. Wildcarding SHOULD be supported for this ACL also. transform and local lifetimes. Wildcarding SHOULD be supported for
such ACL also for Responders that offer public or anonymous services.
8. Changes from RFC 5201 8. Changes from RFC 5201
This section summarizes the changes made from [RFC5201]. This section summarizes the changes made from [RFC5201].
8.1. Changes from draft-ietf-hip-rfc5201-bis-02 8.1. Changes from draft-ietf-hip-rfc5201-bis-03
o Editorial changes to improve clarity and readability.
o Removed obsoleted (not applicable) attack from security
consideration section.
o Added a requirement that hosts MUST support processing of ACK
parameters with several SEQ numbers even when they do not support
sending such parameters.
o Removed note on memory bound puzzles. The use of memory bound
puzzles was reconsidered but no convincing arguments for inclusion
in this document have been made on the list.
o Changed references to reference the new bis documents.
o Specified the ECC curves and the hashes used for these.
o Specified representation of ECC curves in the HI.
o Added text on the dependency between RHASH and HMAC.
o Rephrased part of the security considerations to make them
clearer.
o Clarified the use of HITs in opportunistic mode.
o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as
between SIGNATURE and SIGNATURE_2.
o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to
RESPONDER_BUSY_PLEASE_RETRY.
o Mentioned that there are multiple valid puzzle solutions.
8.2. 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.
8.2. Changes from draft-ietf-hip-rfc5201-bis-01 8.3. 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 101, line 21 skipping to change at page 103, line 26
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.
8.3. Changes from draft-ietf-hip-rfc5201-bis-00 8.4. Changes from draft-ietf-hip-rfc5201-bis-00
o Added reasoning why BIS document is needed. o Added reasoning why BIS document is needed.
8.4. Contents of draft-ietf-hip-rfc5201-bis-00 8.5. Contents of draft-ietf-hip-rfc5201-bis-00
o RFC5201 was submitted as draft-RFC. o RFC5201 was submitted as draft-RFC.
9. Security Considerations 9. 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 so doing, 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.
Denial-of-service attacks often take advantage of the cost of start Denial-of-service attacks often take advantage of asymmetries in the
of state for a protocol on the Responder compared to the 'cheapness' cost of an starting an association. One example of such asymmetry is
on the Initiator. HIP makes no attempt to increase the cost of the the need of a Responder to store local state while a malicious
start of state on the Initiator, but makes an effort to reduce the Initiator can stay stateless. HIP makes no attempt to increase the
cost to the Responder. This is done by having the Responder start cost of the start of state at the Initiator, but makes an effort to
the 3-way exchange instead of the Initiator, making the HIP protocol reduce the cost for the Responder. This is accomplished by having
4 packets long. In doing this, packet 2 becomes a 'stock' packet the Responder start the 3-way exchange instead of the Initiator,
that the Responder MAY use many times, until some Initiator has making the HIP protocol 4 packets long. In doing this, the first
provided a valid response to such an R1 packet. During an I1 storm, packet from the Responder, R1, becomes a 'stock' packet that the
the host may reuse the same DH value also even if some Initiator has Responder MAY use many times, until some Initiator has provided a
valid response to such an R1 packet. During an I1 packet storm, the
host may reuse the same DH value also even if some Initiator has
provided a valid response using that particular DH value. However, provided a valid response using that particular DH value. However,
such behavior is discouraged and should be avoided. Using the same such behavior is discouraged and should be avoided. Using the same
Diffie-Hellman values and random puzzle #I value has some risks. Diffie-Hellman values and random puzzle #I value has some risks.
This risk needs to be balanced against a potential storm of HIP I1 This risk needs to be balanced against a potential storm of HIP I1
packets. packets.
This shifting of the start of state cost to the Initiator in creating This shifting of the start of state cost to the Initiator in creating
the I2 HIP packet, presents another DoS attack. The attacker spoofs the I2 HIP packet presents another DoS attack. The attacker can
the I1 HIP packet and the Responder sends out the R1 HIP packet. spoof the I1 packet and the Responder sends out the R1 HIP packet.
This could conceivably tie up the 'Initiator' with evaluating the R1 This could conceivably tie up the 'Initiator' with evaluating the R1
HIP packet, and creating the I2 HIP packet. The defense against this HIP packet, and creating the I2 packet. The defense against this
attack is to simply ignore any R1 packet where a corresponding I1 was attack is to simply ignore any R1 packet where a corresponding I1
not sent. packet was not sent (as defined in Section 6.8 step 1).
A second form of DoS attack arrives in the I2 HIP packet. Once the A second form of DoS attack arrives in the I2 HIP packet. Once the
attacking Initiator has solved the puzzle, it can send packets with attacking Initiator has solved the puzzle, it can send packets with
spoofed IP source addresses with either an invalid encrypted HIP spoofed IP source addresses with either an invalid encrypted HIP
payload component or a bad HIP signature. This would take resources payload component or a bad HIP signature. This would take resources
in the Responder's part to reach the point to discover that the I2 in the Responder's part to reach the point to discover that the I2
packet cannot be completely processed. The defense against this packet cannot be completely processed. The defense against this
attack is after N bad I2 packets, the Responder would discard any I2s attack is after N bad I2 packets, the Responder would discard any I2
that contain the given Initiator HIT. This will shut down the packets that contain the given Initiator HIT. This will shut down
attack. The attacker would have to request another R1 and use that the attack. The attacker would have to request another R1 packet and
to launch a new attack. The Responder could up the value of K while use that to launch a new attack. The Responder could up the value of
under attack. On the downside, valid I2s might get dropped too. K while under attack. On the downside, valid I2 packets might get
dropped too.
A third form of DoS attack is emulating the restart of state after a A third form of DoS attack is emulating the restart of state after a
reboot of one of the partners. A restarting host would send an I1 to reboot of one of the partners. A restarting host would send an I1
a peer, which would respond with an R1 even if it were in the packet to a peer, which would respond with an R1 packet even if it
ESTABLISHED state. If the I1 were spoofed, the resulting R1 would be were in the ESTABLISHED state. If the I1 packet were spoofed, the
received unexpectedly by the spoofed host and would be dropped, as in resulting R1 packet would be received unexpectedly by the spoofed
the first case above. host and would be dropped, as in the first case above.
A fourth form of DoS attack is emulating the end of state. HIP A fourth form of DoS attack is emulating the end of state. HIP
relies on timers plus a CLOSE/CLOSE_ACK handshake to explicitly relies on timers plus a CLOSE/CLOSE_ACK handshake to explicitly
signal the end of a HIP association. Because both CLOSE and signal the end of a HIP association. Because both CLOSE and
CLOSE_ACK messages contain an HIP_MAC, an outsider cannot close a CLOSE_ACK messages contain an HIP_MAC, an outsider cannot close a
connection. The presence of an additional SIGNATURE allows connection. The presence of an additional SIGNATURE allows
middleboxes to inspect these messages and discard the associated middleboxes to inspect these messages and discard the associated
state (for e.g., firewalling, SPI-based NATing, etc.). However, the state (for e.g., firewalling, SPI-based NATing, etc.). However, the
optional behavior of replying to CLOSE with an ICMP Parameter Problem optional behavior of replying to CLOSE with an ICMP Parameter Problem
packet (as described in Section 5.4.4) might allow an IP spoofer packet (as described in Section 5.4.4) might allow an IP spoofer
skipping to change at page 103, line 10 skipping to change at page 105, line 19
Man-in-the-middle attacks are difficult to defend against, without Man-in-the-middle attacks are difficult to defend against, without
third-party authentication. A skillful MitM could easily handle all third-party authentication. A skillful MitM could easily handle all
parts of HIP, but HIP indirectly provides the following protection parts of HIP, but HIP indirectly provides the following protection
from a MitM attack. If the Responder's HI is retrieved from a signed from a MitM attack. If the Responder's HI is retrieved from a signed
DNS zone, a certificate, or through some other secure means, the DNS zone, a certificate, or through some other secure means, the
Initiator can use this to validate the R1 HIP packet. Initiator can use this to validate the R1 HIP packet.
Likewise, if the Initiator's HI is in a secure DNS zone, a trusted Likewise, if the Initiator's HI is in a secure DNS zone, a trusted
certificate, or otherwise securely available, the Responder can certificate, or otherwise securely available, the Responder can
retrieve the HI (after having got the I2 HIP packet) and verify that retrieve the HI (after having got the I2 HIP packet) and verify that
the HI indeed can be trusted. However, since an Initiator may choose the HI indeed can be trusted.
to use an anonymous HI, it knowingly risks a MitM attack. The
Responder may choose not to accept a HIP exchange with an anonymous
Initiator.
The HIP Opportunistic Mode concept has been introduced in this The HIP Opportunistic Mode concept has been introduced in this
document, but this document does not specify what the semantics of document, but this document does not specify what the semantics of
such a connection setup are for applications. There are certain such a connection setup are for applications. There are certain
concerns with opportunistic mode, as discussed in Section 4.1.8. concerns with opportunistic mode, as discussed in Section 4.1.8.
NOTIFY messages are used only for informational purposes and they are NOTIFY messages are used only for informational purposes and they are
unacknowledged. A HIP implementation cannot rely solely on the unacknowledged. A HIP implementation cannot rely solely on the
information received in a NOTIFY message because the packet may have information received in a NOTIFY message because the packet may have
been replayed. It SHOULD NOT change any state information based been replayed. It SHOULD NOT change any state information purely
purely on a received NOTIFY message. based on a received NOTIFY message.
Since not all hosts will ever support HIP, ICMP 'Destination Protocol Since not all hosts will ever support HIP, ICMP 'Destination Protocol
Unreachable' messages are to be expected and present a DoS attack. Unreachable' messages are to be expected and may be used for a DoS
Against an Initiator, the attack would look like the Responder does attack. Against an Initiator, the attack would look like the
not support HIP, but shortly after receiving the ICMP message, the Responder does not support HIP, but shortly after receiving the ICMP
Initiator would receive a valid R1 HIP packet. Thus, to protect from message, the Initiator would receive a valid R1 HIP packet. Thus, to
this attack, an Initiator should not react to an ICMP message until a protect from this attack, an Initiator should not react to an ICMP
reasonable delta time to get the real Responder's R1 HIP packet. A message until a reasonable delta time to get the real Responder's R1
similar attack against the Responder is more involved. Normally, if HIP packet. A similar attack against the Responder is more involved.
an I1 message received by a Responder was a bogus one sent by an Normally, if an I1 message received by a Responder was a bogus one
attacker, the Responder may receive an ICMP message from the IP sent by an attacker, the Responder may receive an ICMP message from
address the R1 message was sent to. However, a sophisticated the IP address the R1 message was sent to. However, a sophisticated
attacker can try to take advantage of such a behavior and try to attacker can try to take advantage of such a behavior and try to
break up the HIP exchange by sending such an ICMP message to the break up the HIP exchange by sending such an ICMP message to the
Responder before the Initiator has a chance to send a valid I2 Responder before the Initiator has a chance to send a valid I2
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.
10. IANA Considerations 10. IANA Considerations
IANA has reserved protocol number 139 for the Host Identity Protocol. IANA has reserved protocol number 139 for the Host Identity Protocol.
This document defines a new 128-bit value under the CGA Message Type This document defines a new 128-bit value under the CGA Message Type
namespace [RFC3972], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, to be namespace [RFC3972], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, to be
used for HIT generation as specified in ORCHID [RFC4843-bis]. used for HIT generation as specified in ORCHID
[I-D.ietf-hip-rfc4843-bis].
This document also creates a set of new namespaces. These are This document also creates a set of new namespaces. These are
described below. described below.
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. The current values are defined in Sections 5.3.1 through 5.3.8.
skipping to change at page 107, line 12 skipping to change at page 109, line 18
changes were introduced through the working group process. Most changes were introduced through the working group process. Most
notably, the original document was split in two, one containing the notably, the original document was split in two, one containing the
base exchange and the other one defining how to use ESP. Some base exchange and the other one defining how to use ESP. Some
modifications to the protocol proposed by Aura, et al., [AUR03] were modifications to the protocol proposed by Aura, et al., [AUR03] were
added at a later stage. added at a later stage.
12. References 12. References
12.1. Normative References 12.1. Normative References
[FIPS.180-2.2002] National Institute of Standards and Technology, [FIPS.180-2.2002] National Institute of Standards and
"Secure Hash Standard", FIPS PUB 180-2, Technology, "Secure Hash Standard",
August 2002, <http://csrc.nist.gov/publications/ FIPS PUB 180-2, August 2002, <http://
fips/fips180-2/fips180-2.pdf>. csrc.nist.gov/publications/fips/
fips180-2/fips180-2.pdf>.
[FIPS.95-1.1993] National Institute of Standards and Technology, [FIPS.95-1.1993] National Institute of Standards and
"Codes for the Identification of Federal and Technology, "Codes for the
Federally Assisted Organizations", FIPS PUB 95-1, Identification of Federal and Federally
January 1993. Assisted Organizations", FIPS PUB 95-1,
January 1993.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, [I-D.ietf-hip-rfc4843-bis] Laganier, J. and F. Dupont, "An IPv6
RFC 768, August 1980. Prefix for Overlay Routable
Cryptographic Hash Identifiers
(ORCHID)",
draft-ietf-hip-rfc4843-bis-00 (work in
progress), August 2010.
[RFC1035] Mockapetris, P., "Domain names - implementation [I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., Nikander,
and specification", STD 13, RFC 1035, P., and J. Melen, "Using the
November 1987. Encapsulating Security Payload (ESP)
Transport Format with the Host Identity
Protocol (HIP)",
draft-ietf-hip-rfc5202-bis-00 (work in
progress), September 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to [I-D.mcgrew-fundamental-ecc] McGrew, D., Igoe, K., and M. Salter,
Indicate Requirement Levels", BCP 14, RFC 2119, "Fundamental Elliptic Curve
March 1997. Cryptography Algorithms",
draft-mcgrew-fundamental-ecc-03 (work
in progress), May 2010.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 [RFC0768] Postel, J., "User Datagram Protocol",
within ESP and AH", RFC 2404, November 1998. STD 6, RFC 768, August 1980.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher [RFC1035] Mockapetris, P., "Domain names -
Algorithms", RFC 2451, November 1998. implementation and specification",
STD 13, RFC 1035, November 1987.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, [RFC2119] Bradner, S., "Key words for use in RFCs
Version 6 (IPv6) Specification", RFC 2460, to Indicate Requirement Levels",
December 1998. BCP 14, RFC 2119, March 1997.
[RFC2463] Conta, A. and S. Deering, "Internet Control [RFC2404] Madson, C. and R. Glenn, "The Use of
Message Protocol (ICMPv6) for the Internet HMAC-SHA-1-96 within ESP and AH",
Protocol Version 6 (IPv6) Specification", RFC 2404, November 1998.
RFC 2463, December 1998.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-
Name System (DNS)", RFC 2536, March 1999. Mode Cipher Algorithms", RFC 2451,
November 1998.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC2460] Deering, S. and R. Hinden, "Internet
Specification Version 2.0", RFC 2898, Protocol, Version 6 (IPv6)
September 2000. Specification", RFC 2460,
December 1998.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the [RFC2463] Conta, A. and S. Deering, "Internet
Domain Name System (DNS)", RFC 3110, May 2001. Control Message Protocol (ICMPv6) for
the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463,
December 1998.
[RFC3484] Draves, R., "Default Address Selection for [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the
Internet Protocol version 6 (IPv6)", RFC 3484, Domain Name System (DNS)", RFC 2536,
February 2003. March 1999.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential [RFC2898] Kaliski, B., "PKCS #5: Password-Based
(MODP) Diffie-Hellman groups for Internet Key Cryptography Specification Version
Exchange (IKE)", RFC 3526, May 2003. 2.0", RFC 2898, September 2000.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA
Cipher Algorithm and Its Use with IPsec", KEYs in the Domain Name System (DNS)",
RFC 3602, September 2003. RFC 3110, May 2001.
[RFC3972] Aura, T., "Cryptographically Generated Addresses [RFC3484] Draves, R., "Default Address Selection
(CGA)", RFC 3972, March 2005. for Internet Protocol version 6
(IPv6)", RFC 3484, February 2003.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., [RFC3526] Kivinen, T. and M. Kojo, "More Modular
and S. Rose, "Resource Records for the DNS Exponential (MODP) Diffie-Hellman
Security Extensions", RFC 4034, March 2005. groups for Internet Key Exchange
(IKE)", RFC 3526, May 2003.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, [RFC3602] Frankel, S., Glenn, R., and S. Kelly,
"The Network Access Identifier", RFC 4282, "The AES-CBC Cipher Algorithm and Its
December 2005. Use with IPsec", RFC 3602,
September 2003.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in [RFC3972] Aura, T., "Cryptographically Generated
the Internet Key Exchange Version 2 (IKEv2)", Addresses (CGA)", RFC 3972, March 2005.
RFC 4307, December 2005.
[RFC4753] Fu, D. and J. Solinas, "ECP Groups For IKE and [RFC4034] Arends, R., Austein, R., Larson, M.,
IKEv2", RFC 4753, January 2007. Massey, D., and S. Rose, "Resource
Records for the DNS Security
Extensions", RFC 4034, March 2005.
[RFC4843-bis] Nikander, P., Laganier, J., and F. Dupont, "STUB: [RFC4282] Aboba, B., Beadles, M., Arkko, J., and
An IPv6 Prefix for Overlay Routable Cryptographic P. Eronen, "The Network Access
Hash Identifiers (ORCHID)", Identifier", RFC 4282, December 2005.
draft-laganier-rfc4843-bis-00 (work in progress),
February 2010.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, [RFC4753] Fu, D. and J. Solinas, "ECP Groups For
HMAC-SHA-384, and HMAC-SHA-512 with IPsec", IKE and IKEv2", RFC 4753, January 2007.
RFC 4868, May 2007.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2
Henderson, "Host Identity Protocol", RFC 5201, Authentication Using the Elliptic Curve
April 2008. Digital Signature Algorithm (ECDSA)",
RFC 4754, January 2007.
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-
the Encapsulating Security Payload (ESP) Transport SHA-256, HMAC-SHA-384, and HMAC-SHA-512
Format with the Host Identity Protocol (HIP)", with IPsec", RFC 4868, May 2007.
RFC 5202, April 2008.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in [RFC5201] Moskowitz, R., Nikander, P., Jokela,
DNSKEY and RRSIG Resource Records for DNSSEC", P., and T. Henderson, "Host Identity
RFC 5702, October 2009. Protocol", RFC 5201, April 2008.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract- [RFC5702] Jansen, J., "Use of SHA-2 Algorithms
and-Expand Key Derivation Function (HKDF)", with RSA in DNSKEY and RRSIG Resource
RFC 5869, May 2010. Records for DNSSEC", RFC 5702,
October 2009.
[fundamental-ecc] McGrew, D. and K. Igoe, "Fundamental Elliptic [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based
Curve Cryptography Algorithms", Extract-and-Expand Key Derivation
draft-mcgrew-fundamental-ecc-03 (work in Function (HKDF)", RFC 5869, May 2010.
progress), May 2010.
12.2. Informative References 12.2. Informative References
[AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis [AUR03] Aura, T., Nagarajan, A., and A. Gurtov,
of the HIP Base Exchange Protocol", in Proceedings "Analysis of the HIP Base Exchange
of 10th Australasian Conference on Information Protocol", in Proceedings of 10th
Security and Privacy, July 2003. Australasian Conference on Information
Security and Privacy, July 2003.
[CRO03] Crosby, SA. and DS. Wallach, "Denial of Service [CRO03] Crosby, SA. and DS. Wallach, "Denial of
via Algorithmic Complexity Attacks", in Service via Algorithmic Complexity
Proceedings of Usenix Security Symposium 2003, Attacks", in Proceedings of Usenix
Washington, DC., August 2003. Security Symposium 2003, Washington,
DC., August 2003.
[DIF76] Diffie, W. and M. Hellman, "New Directions in [DIF76] Diffie, W. and M. Hellman, "New
Cryptography", IEEE Transactions on Information Directions in Cryptography", IEEE
Theory vol. IT-22, number 6, pages 644-654, Transactions on Information Theory vol.
Nov 1976. IT-22, number 6, pages 644-654,
Nov 1976.
[FIPS.197.2001] National Institute of Standards and Technology, [FIPS.197.2001] National Institute of Standards and
"Advanced Encryption Standard (AES)", FIPS PUB Technology, "Advanced Encryption
197, November 2001, <http://csrc.nist.gov/ Standard (AES)", FIPS PUB 197,
publications/fips/fips197/fips-197.pdf>. November 2001, <http://csrc.nist.gov/
publications/fips/fips197/
fips-197.pdf>.
[KAU03] Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS [I-D.ietf-btns-c-api] Richardson, M., Williams, N., Komu, M.,
protection for UDP-based protocols", ACM and S. Tarkoma, "C-Bindings for IPsec
Conference on Computer and Communications Application Programming Interfaces",
Security , Oct 2003. draft-ietf-btns-c-api-04 (work in
progress), March 2009.
[KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol
to Authenticated Diffie-Hellman and Its Use in the Architecture",
IKE-Protocols", in Proceedings of CRYPTO 2003, draft-ietf-hip-rfc4423-bis-01 (work in
pages 400-425, August 2003. progress), August 2010.
[RFC0792] Postel, J., "Internet Control Message Protocol", [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host
STD 5, RFC 792, September 1981. Identity Protocol (HIP) Rendezvous
Extension",
draft-ietf-hip-rfc5204-bis-00 (work in
progress), August 2010.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for [I-D.ietf-hip-rfc5205-bis] Laganier, J., "Host Identity Protocol
Writing an IANA Considerations Section in RFCs", (HIP) Domain Name System (DNS)
BCP 26, RFC 2434, October 1998. Extension",
draft-ietf-hip-rfc5205-bis-00 (work in
progress), August 2010.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) [I-D.ietf-hip-rfc5206-bis] Nikander, P., Henderson, T., Vogt, C.,
Protocol", RFC 4306, December 2005. and J. Arkko, "Host Mobility with the
Host Identity Protocol",
draft-ietf-hip-rfc5206-bis-01 (work in
progress), October 2010.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity [KAU03] Kaufman, C., Perlman, R., and B.
Protocol (HIP) Rendezvous Extension", RFC 5204, Sommerfeld, "DoS protection for UDP-
April 2008. based protocols", ACM Conference on
Computer and Communications Security ,
Oct 2003.
[RFC5205] Nikander, P. and J. Laganier, "Host Identity [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-
Protocol (HIP) Domain Name System (DNS) MAc' Approach to Authenticated Diffie-
Extensions", RFC 5205, April 2008. Hellman and Its Use in the IKE-
Protocols", in Proceedings of CRYPTO
2003, pages 400-425, August 2003.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. [RFC0792] Postel, J., "Internet Control Message
Arkko, "End-Host Mobility and Multihoming with the Protocol", STD 5, RFC 792,
Host Identity Protocol", RFC 5206, April 2008. September 1981.
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using [RFC2434] Narten, T. and H. Alvestrand,
the Host Identity Protocol with Legacy "Guidelines for Writing an IANA
Applications", RFC 5338, September 2008. Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 [RFC4306] Kaufman, C., "Internet Key Exchange
Multihoming Shim Protocol for IPv6", RFC 5533, (IKEv2) Protocol", RFC 4306,
June 2009. December 2005.
[btns-c-api] Richardson, M., Williams, N., Komu, M., and S. [RFC5338] Henderson, T., Nikander, P., and M.
Tarkoma, "C-Bindings for IPsec Application Komu, "Using the Host Identity Protocol
Programming Interfaces", draft-ietf-btns-c-api-04 with Legacy Applications", RFC 5338,
(work in progress), March 2009. September 2008.
[rfc4423-bis] Moskowitz, R., "Host Identity Protocol [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6:
Architecture", draft-moskowitz-hip-rfc4423-bis-01 Level 3 Multihoming Shim Protocol for
(work in progress), June 2010. IPv6", RFC 5533, June 2009.
[SECG] SECG, "Recommended Elliptic Curve
Domain Parameters", SEC 2 , 2000,
<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 I2s by using a number of pre-calculated and still reject most spoofed I2 packets by using a number of pre-
R1s and a local selection function. This appendix defines one calculated R1 packets and a local selection function. This appendix
possible implementation in detail. The purpose of this appendix is defines one possible implementation in detail. The purpose of this
to give the implementors an idea on how to implement the mechanism. appendix is to give the implementors an idea on how to implement the
If the implementation is based on this appendix, it MAY contain some mechanism. If the implementation is based on this appendix, it MAY
local modification that makes an attacker's task harder. contain some local modification that makes an attacker's task harder.
The Responder creates a secret value S, that it regenerates The Responder creates a secret value S, that it regenerates
periodically. The Responder needs to remember the two latest values periodically. The Responder needs to remember the two latest values
of S. Each time the S is regenerated, the R1 generation counter of S. Each time the S is regenerated, the R1 generation counter
value is incremented by one. value is incremented by one.
The Responder generates a pre-signed R1 packet. The signature for The Responder generates a pre-signed R1 packet. The signature for
pre-generated R1s must be recalculated when the Diffie-Hellman key is pre-generated R1s must be recalculated when the Diffie-Hellman key is
recomputed or when the R1_COUNTER value changes due to S value recomputed or when the R1_COUNTER value changes due to S value
regeneration. regeneration.
When the Initiator sends the I1 packet for initializing a connection, When the Initiator sends the I1 packet for initializing a connection,
the Responder gets the HIT and IP address from the packet, and the Responder receives the HIT and IP address from the packet, and
generates an I value for the puzzle. The I value is set to the pre- generates an I value for the puzzle. The I value is set to the pre-
signed R1 packet. signed R1 packet.
I value calculation: I value calculation:
I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n) I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n)
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 gets 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 the 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 verify 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 do not the solution using I, J, and difficulty K. If the I values do not
match, the I2 is dropped. 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
skipping to change at page 112, line 47 skipping to change at page 115, line 47
Appendix C. Example Checksums for HIP Packets Appendix C. Example Checksums for HIP Packets
The HIP checksum for HIP packets is specified in Section 5.1.1. The HIP checksum for HIP packets is specified in Section 5.1.1.
Checksums for TCP and UDP packets running over HIP-enabled security Checksums for TCP and UDP packets running over HIP-enabled security
associations are specified in Section 3.5. The examples below use IP associations are specified in Section 3.5. The examples below use IP
addresses of 192.168.0.1 and 192.168.0.2 (and their respective IPv4- addresses of 192.168.0.1 and 192.168.0.2 (and their respective IPv4-
compatible IPv6 formats), and HITs with the prefix of 2001:10 compatible IPv6 formats), and HITs with the prefix of 2001:10
followed by zeros, followed by a decimal 1 or 2, respectively. followed by zeros, followed by a decimal 1 or 2, respectively.
The following example is defined only for testing a checksum The following example is defined only for testing the checksum
calculation. The address format for the IPv4-compatible IPv6 address calculation. The address format for the IPv4-compatible IPv6 address
is not a valid one, but using these IPv6 addresses when testing an is not a valid one, but using these IPv6 addresses when testing an
IPv6 implementation gives the same checksum output as an IPv4 IPv6 implementation gives the same checksum output as an IPv4
implementation with the corresponding IPv4 addresses. implementation with the corresponding IPv4 addresses.
C.1. IPv6 HIP Example (I1) C.1. IPv6 HIP Example (I1 packet)
Source Address: ::192.168.0.1 Source Address: ::192.168.0.1
Destination Address: ::192.168.0.2 Destination Address: ::192.168.0.2
Upper-Layer Packet Length: 40 0x28 Upper-Layer Packet Length: 40 0x28
Next Header: 139 0x8b Next Header: 139 0x8b
Payload Protocol: 59 0x3b Payload Protocol: 59 0x3b
Header Length: 4 0x4 Header Length: 4 0x4
Packet Type: 1 0x1 Packet Type: 1 0x1
Version: 1 0x1 Version: 1 0x1
Reserved: 1 0x1 Reserved: 1 0x1
Control: 0 0x0 Control: 0 0x0
Checksum: 446 0x1be Checksum: 446 0x1be
Sender's HIT : 2001:10::1 Sender's HIT : 2001:10::1
Receiver's HIT: 2001:10::2 Receiver's HIT: 2001:10::2
C.2. IPv4 HIP Packet (I1) C.2. IPv4 HIP Packet (I1 packet)
The IPv4 checksum value for the same example I1 packet is the same as The IPv4 checksum value for the same example I1 packet is the same as
the IPv6 checksum (since the checksums due to the IPv4 and IPv6 the IPv6 checksum (since the checksums due to the IPv4 and IPv6
pseudo-header components are the same). pseudo-header components are the same).
C.3. TCP Segment C.3. TCP Segment
Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets
use the IPv6 pseudo-header format [RFC2460], with the HITs used in use the IPv6 pseudo-header format [RFC2460], with the HITs used in
place of the IPv6 addresses. place of the IPv6 addresses.
skipping to change at page 114, line 5 skipping to change at page 117, line 5
Flags: SYN 0x02 Flags: SYN 0x02
Window size: 65535 0xffff Window size: 65535 0xffff
Checksum: 28618 0x6fca Checksum: 28618 0x6fca
Urgent pointer: 0 0x0000 Urgent pointer: 0 0x0000
0x0000: 6000 0000 0014 0640 2001 0010 0000 0000 0x0000: 6000 0000 0014 0640 2001 0010 0000 0000
0x0010: 0000 0000 0000 0001 2001 0010 0000 0000 0x0010: 0000 0000 0000 0001 2001 0010 0000 0000
0x0020: 0000 0000 0000 0002 ffdc 0016 0000 0001 0x0020: 0000 0000 0000 0002 ffdc 0016 0000 0001
0x0030: 0000 0000 5002 ffff 6fca 0000 0x0030: 0000 0000 5002 ffff 6fca 0000
Appendix D. ECDH-160 Group Appendix D. ECDH and ECDSA 160 Bit Groups
The ECDH-160 group is rated at 80 bits strength. Once this was The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits
considered appropriate for one year of security. Today should be symmetric strength. Once this was considered appropriate for one</