draft-ietf-hip-rfc5201-bis-02.txt   draft-ietf-hip-rfc5201-bis-03.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: March 7, 2011 T. Henderson Expires: April 26, 2011 T. Henderson
The Boeing Company The Boeing Company
T. Heer T. Heer
RWTH Aachen University, RWTH Aachen University,
Distributed Systems Group Distributed Systems Group
September 3, 2010 October 23, 2010
Host Identity Protocol Host Identity Protocol
draft-ietf-hip-rfc5201-bis-02 draft-ietf-hip-rfc5201-bis-03
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 38
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 in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF), its areas, and its working groups. Note that
working documents as Internet-Drafts. The list of current Internet- other groups may also distribute working documents as Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 7, 2011. 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.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the 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 46 skipping to change at page 3, line 4
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 . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . 17
4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 18 4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 18
4.1.6. Aborting a HIP Exchange . . . . . . . . . . . . . . . 18 4.1.6. Aborting a HIP Exchange . . . . . . . . . . . . . . . 19
4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 19 4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 19
4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 20 4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 20
4.2. Updating a HIP Association . . . . . . . . . . . . . . . 22 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 23
4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 23 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 23
4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 24 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 24
4.4.1. Timespan Definitions . . . . . . . . . . . . . . . . 24 4.4.1. Timespan Definitions . . . . . . . . . . . . . . . . 25
4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 25 4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 25
4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 26 4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 26
4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 33 4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 33
4.5. User Data Considerations . . . . . . . . . . . . . . . . 35 4.5. User Data Considerations . . . . . . . . . . . . . . . . 35
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 . 35
4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 35 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 35
4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 35 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 35
4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 35 4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 35
4.6. Certificate Distribution . . . . . . . . . . . . . . . . 36 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 36
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 36 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 36
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 36 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 36
5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 37 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 37
5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 38 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 38
5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 38 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 38
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 39 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 39
5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 42 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 42
5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 43 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 44
5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 44 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 45
5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 45 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 46 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 47
5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 47 5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 48
5.2.7. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 48 5.2.7. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 49
5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 49 5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.9. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 51 5.2.9. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 52
5.2.10. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 52 5.2.10. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 53
5.2.11. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 53 5.2.11. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.12. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 53 5.2.12. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 54
5.2.13. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 54 5.2.13. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 55
5.2.14. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 55 5.2.14. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 56
5.2.15. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.2.15. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.16. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.2.16. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.17. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 57 5.2.17. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 58
5.2.18. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 58 5.2.18. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 59
5.2.19. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 62 5.2.19. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 63
5.2.20. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 62 5.2.20. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 63
5.2.21. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 63 5.2.21. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 64
5.2.22. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 64 5.2.22. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 65
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 64 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 65
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 65 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 66
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 66 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 67
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 69 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 70
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 70 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 71
5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 70 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 71
5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 71 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 72
5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 72 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 73
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 72 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 73
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 73 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 74
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 73 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 74
5.4.2. Other Problems with the HIP Header and Packet 5.4.2. Other Problems with the HIP Header and Packet
Structure . . . . . . . . . . . . . . . . . . . . . . 73 Structure . . . . . . . . . . . . . . . . . . . . . . 74
5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 73 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 74
5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 74 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 75
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 74 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 75
6.1. Processing Outgoing Application Data . . . . . . . . . . 74 6.1. Processing Outgoing Application Data . . . . . . . . . . 75
6.2. Processing Incoming Application Data . . . . . . . . . . 75 6.2. Processing Incoming Application Data . . . . . . . . . . 76
6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 76 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 77
6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 78 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 79
6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 78 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 79
6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 80 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 81
6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 82 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 83
6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 83 6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 84
6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 84 6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 85
6.6.2. Processing Incoming ICMP Protocol Unreachable 6.6.2. Processing Incoming ICMP Protocol Unreachable
Messages . . . . . . . . . . . . . . . . . . . . . . 85 Messages . . . . . . . . . . . . . . . . . . . . . . 86
6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 85 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 86
6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 86 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 87
6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 87 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 88
6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 87 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 88
6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 89 6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 90
6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 89 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 90
6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 92 6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 93
6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 92 6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 93
6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 93 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 94
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 94 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 95
6.12.1. Handling a SEQ Parameter in a Received UPDATE 6.12.1. Handling a SEQ Parameter in a Received UPDATE
Message . . . . . . . . . . . . . . . . . . . . . . . 95 Message . . . . . . . . . . . . . . . . . . . . . . . 96
6.12.2. Handling an ACK Parameter in a Received UPDATE 6.12.2. Handling an ACK Parameter in a Received UPDATE
Packet . . . . . . . . . . . . . . . . . . . . . . . 95 Packet . . . . . . . . . . . . . . . . . . . . . . . 96
6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 96 6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 97
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 96 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 97
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 97 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 98
6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 97 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 98
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 97 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 98
8. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 98 8. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 99
8.1. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 98 8.1. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 99
8.2. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 100 8.2. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 99
8.3. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . . 100 8.3. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 101
8.4. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . . 101
9. Security Considerations . . . . . . . . . . . . . . . . . . . 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 101
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 102 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 104 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 106
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 107
12.1. Normative References . . . . . . . . . . . . . . . . . . 105 12.1. Normative References . . . . . . . . . . . . . . . . . . 107
12.2. Informative References . . . . . . . . . . . . . . . . . 108 12.2. Informative References . . . . . . . . . . . . . . . . . 109
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 109 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 110
Appendix B. Generating a Public Key Encoding from an HI . . . . 110 Appendix B. Generating a Public Key Encoding from an HI . . . . 112
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 111 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 112
C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 112 C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 113
C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 112 C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 113
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 112 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 113
Appendix D. ECDH-160 Group . . . . . . . . . . . . . . . . . . . 113 Appendix D. ECDH-160 Group . . . . . . . . . . . . . . . . . . . 114
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 113 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 114
1. Introduction 1. Introduction
This memo specifies the details of the Host Identity Protocol (HIP). This memo specifies the details of the Host Identity Protocol (HIP).
A high-level description of the protocol and the underlying 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 [rfc4423-bis]. Briefly, the HIP architecture proposes an
alternative to the dual use of IP addresses as "locators" (routing alternative to the dual use of IP addresses as "locators" (routing
labels) and "identifiers" (endpoint, or host, identifiers). In HIP, labels) and "identifiers" (endpoint, or host, identifiers). In HIP,
public cryptographic keys, of a public/private key pair, are used as public cryptographic keys, of a public/private key pair, are used as
skipping to change at page 6, line 47 skipping to change at page 6, line 47
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 [RFC5205]: how to extend DNS to contain Host Identity information
o "Host Identity Protocol (HIP) Rendezvous Extension" [RFC5204]: o "Host Identity Protocol (HIP) Rendezvous Extension" [RFC5204]:
using a rendezvous mechanism to contact mobile HIP hosts 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
cryptograhic primative 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 adds this needed cryptographic agility
while addressing the downgrade attacks that such flexibility enables. while addressing the downgrade attacks that such flexibility enables.
In particular, Elliptic Curve support (ECDSA and ECDH) and In particular, Elliptic Curve support (ECDSA and ECDH) and
alternative hash functions have been added. 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
skipping to change at page 15, line 28 skipping to change at page 15, line 28
PUZZLE parameter (Section 5.2.4). The Responder needs to re-create PUZZLE parameter (Section 5.2.4). The Responder needs to re-create
the concatenation of I, the HITs, and the provided J, and compute the the concatenation of I, the HITs, and the provided J, and compute the
hash once to prove that the Initiator did its assigned task. hash once to prove that the Initiator did 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 an ECHO_REQUEST_SIGNED Using the Opaque data field in the PUZZLE (Section 5.2.4), in an
(Section 5.2.19) or in an ECHO_REQUEST_UNSIGNED parameter ECHO_REQUEST_SIGNED (Section 5.2.19) or in an ECHO_REQUEST_UNSIGNED
(Section 5.2.20), the Responder can include some data in R1 that the parameter (Section 5.2.20), the Responder can include some data in R1
Initiator must copy unmodified in the corresponding I2 packet. The that the Initiator must copy unmodified in the corresponding I2
Responder can generate the Opaque data in various ways; e.g., using packet. The Responder can generate the Opaque data in various ways;
encryption or hashing with some secret, the sent I, and possibly e.g., using encryption or hashing with some secret, the sent I, and
other related data. Using the same secret, the received I (from the possibly other related data. Using the same secret, the received I
I2), and the other related data (if any), the Receiver can verify (from the I2), and the other related data (if any), the Receiver can
that it has itself sent the I to the Initiator. The Responder MUST verify that it has itself sent the I to the Initiator. The Responder
periodically change such a used secret. MUST periodically change such a used secret.
It is RECOMMENDED that the Responder generates a new puzzle and new It is RECOMMENDED that the Responder generates new secrets for the
R1s once every few minutes. Furthermore, it is RECOMMENDED that the puzzle and new R1s once every few minutes. Furthermore, it is
Responder remembers an old puzzle at least Lifetime seconds after the RECOMMENDED that the Responder is able to verify valid puzzle
puzzle has been deprecated. These time values guarantee that the solution at least Lifetime seconds after the puzzle secret has been
puzzle is valid for at least Lifetime and at most 2*Lifetime seconds. deprecated. These time values guarantee that the puzzle is valid for
This limits the usability that an old, solved puzzle has to an at least Lifetime and at most 2*Lifetime seconds. This limits the
attacker. usability that an old, solved puzzle has to an attacker.
The puzzle value I and the solution J are inputs for deriving the
keying material from the Diffie Hellman key exchange (Section 6.5).
Therefore, a Responder SHOULD NOT use the same puzzle I with the same
DH keys for the same Initiator twice to ensure that the derived
keying material differs. Such uniqueness can be achieved, for
example, by using a counter as additional input for generating I.
This counter can be increased for each processed I1 packet. The
state of the counter can be transmitted in the Opaque data field in
the PUZZLE (Section 5.2.4), in an ECHO_REQUEST_SIGNED
(Section 5.2.19) or in an ECHO_REQUEST_UNSIGNED parameter
(Section 5.2.20) without the need 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.
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. At
the time of the decision, the idea of memory-bound functions was the time of the decision, the idea of memory-bound functions was
relatively new and their IPR status were unknown. Once there is more relatively new and their IPR status were unknown. Once there is more
skipping to change at page 28, line 28 skipping to change at page 28, line 28
| | | | | |
| | 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 |
| | | | | |
| Receive R2, process | If successful, go to ESTABLISHED | | Receive R2, process | If successful, go to ESTABLISHED |
| | | | | |
| | If fail, stay at I2-SENT | | | If fail, stay at I2-SENT |
| | | | | |
| Receive CLOSE, | If successful, send CLOSE_ACK and go to |
| process | CLOSED |
| | |
| | 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 | If counter is less than I2_RETRIES_MAX, |
| timeout counter | send I2 and stay at I2-SENT | | timeout counter | 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
skipping to change at page 29, line 25 skipping to change at page 29, line 25
| | | | | |
| 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 | |
| | | | | |
| Exchange Complete | Move to ESTABLISHED | | Exchange Complete | Move to ESTABLISHED |
| Timeout | | | Timeout | |
| | |
| Receive CLOSE, | If successful, send CLOSE_ACK and go to |
| process | CLOSED |
| | |
| | If fail, stay at ESTABLISHED |
| | |
| Receive NOTIFY | Process and stay at R2-SENT |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 5: R2-SENT - Waiting to finish HIP Table 5: R2-SENT - Waiting to finish HIP
System behavior in state ESTABLISHED, Table 6. System behavior in state ESTABLISHED, Table 6.
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Trigger | Action | | Trigger | Action |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Receive I1 | Send R1 and stay at ESTABLISHED | | Receive I1 | Send R1 and stay at ESTABLISHED |
skipping to change at page 30, line 30 skipping to change at page 30, line 30
| | | | | |
| 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 | |
| | | | | |
| No packet | Send CLOSE and go to CLOSING | | No packet | Send CLOSE and go to CLOSING |
| sent/received | | | sent/received | |
| during UAL minutes | | | during UAL minutes | |
| | | | | |
| Receive UPDATE | Process and stay at ESTABLISHED |
| | |
| 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 ESTABLISHED | | | If fail, stay at ESTABLISHED |
| | |
| Receive CLOSE_ACK | Drop and stay at ESTABLISHED |
| | |
| Receive NOTIFY | Process and stay at ESTABLISHED |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 6: ESTABLISHED - HIP association established Table 6: ESTABLISHED - HIP association established
System behavior in state CLOSING, Table 7. System behavior in state CLOSING, Table 7.
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Trigger | Action | | Trigger | Action |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| User data to send, | Send I1 and stay at CLOSING | | User data to send, | Send I1 and stay at CLOSING |
skipping to change at page 32, line 47 skipping to change at page 32, 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.
+-+ +----------------------------+ +--+ +----------------------------+
I1 received, send R1 | | | | recv I1, send R1 | | | |
| v v | | v v |
Datagram to send +--------------+ I2 received, send R2 | +--------------+ recv I2, send R2 |
+---------------| UNASSOCIATED |----------------+ | +----------------| UNASSOCIATED |----------------+ |
| +-+ +--------------+ | | datagram| +--+ +--------------+ | |
Send I1 | | | Alg. not supported, send I1 | | to send,| | | Alg. not supported, | |
v | v | | send I1| | | send I1 | |
+---------+ I2 received, send R2 | | v | v | |
+---->| I1-SENT |---------------------------------------+ | | +---------+ recv I2, send R2 | |
| +---------+ | | | +---->| I1-SENT |--------------------------------------+ | |
| | +------------------------+ | | | | +---------+ | | |
| | R1 received, | I2 received, send R2 | | | | | | +----------------------+ | | |
| v send I2 | v v v | | | recv R2, | recv I2, send R2 | | | |
| +---------+ | +---------+ | | v send I2 | v v v |
| +->| I2-SENT |------------+ | R2-SENT |<----+ | | +---------+ | +---------+ |
| | +---------+ +---------+ | | | +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ |
| | | | | | | | +---------+ | +---------+ | |
| | | data| | | | | | | | | | |
| |receive | or| | | | | | |recv R2 | data or| | |
| |R1, send | EC timeout| receive I2,| | | |recv R1, | | | EC timeout| | |
| |I2 |R2 received +--------------+ | send R2| | | |send I2 +--|-----------------+ | receive I2,| |
| | +----------->| ESTABLISHED |<--------+ | | | | | | +-------------+ | send R2| |
| | +--------------+ | | | | | +------>| ESTABLISHED |<----------+ | |
| | | | | receive I2, send R2 | | | | | +-------------+ | |
| | recv+------------+ | +------------------------+ | | | | | | | receive I2, send R2 | |
| | CLOSE,| | | | | | +------------+ | +-------------------------------+ |
| | send| No packet sent| | | | | | +-----------+ | |
| | CLOSE_ACK| /received for | timeout | | | | | no packet sent/received| +---+ | |
| | | UAL min, send | +---------+<-+ (UAL+MSL) | | | | | for UAL min, send CLOSE| | |timeout | |
| | | CLOSE +--->| CLOSING |--+ retransmit | | | | | v v |(UAL+MSL) | |
| | | +---------+ CLOSE | | | | | +---------+ |retransmit | |
+--|------------|----------------------+| | | | | | +--|----------|------------------------| CLOSING |-+CLOSE | |
+------------|-----------------------+ | | +-----------------+ | | | +---------+ | |
| | +-----------+ +-------------------|--+ | | | | | | | |
| +-----------+ | receive CLOSE, CLOSE_ACK | | +----------|-------------------------+ | | +----------------+ |
| | | send CLOSE_ACK received or | | | | +-----------+ +------------------|--+
| | | timeout | | | | |recv CLOSE, recv CLOSE_ACK | |
| | | (UAL+MSL) | | | | |send CLOSE_ACK or timeout | |
| v v | | | +-------------+ | (UAL+MSL) | |
| +--------+ receive I2, send R2 | | | recv CLOSE, | | | |
+-----------------------| CLOSED |----------------------------+ | | send CLOSE_ACK v v | |
+--------+ /-----------------------+ | +--------+ receive I2, send R2 | |
^ | \-------/ timeout (UAL+2MSL), +---------------------| CLOSED |------------------------------+ |
| | move to UNASSOCIATED +--------+ |
+-+ ^ | | |
CLOSE received, send CLOSE_ACK recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) |
+-+ +------------------------------------+
4.5. User Data Considerations 4.5. User Data Considerations
4.5.1. TCP and UDP Pseudo-Header Computation for User Data 4.5.1. TCP and UDP Pseudo-Header Computation for User Data
When computing TCP and UDP checksums on user data packets that flow When computing TCP and UDP checksums on user data packets that flow
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
skipping to change at page 40, line 41 skipping to change at page 40, 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 41, 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. | | | | | from KEYMAT. Compared |
| | | | Compared to HIP_MAC, | | | | | to HIP_MAC, the |
| | | | the HOST_ID parameter | | | | | HOST_ID parameter is |
| | | | is included in | | | | | included in HIP_MAC_2 |
| | | | 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 Because 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. Parameters numbered between 0-1023 are used in HIP extensions.
handshake and update procedures and are covered by signatures.
Parameters numbered between 1024-2047 are reserved. Parameters The following parameter type number ranges are defined.
numbered between 2048-4095 are used for parameters that are covered
by a signature but may also be present in packets without signatures. +---------------+---------------------------------------------------+
Parameters numbered between 4096 and (2^16 - 2^12) 61439 are | Type Range | Purpose |
reserved. Parameters numbered between 61440-62463 are used for +---------------+---------------------------------------------------+
signatures and signed MACs. Parameters numbered between 62464-63487 | 0 - 1023 | Handshake |
are used for parameters that fall outside of the signed area of the | | |
packet. Parameters numbered between 63488-64511 are used for | 1024 - 2047 | Reserved |
rendezvous and other relaying services. Parameters numbered between | | |
64512-65535 are reserved. | 2048 - 8191 | Signed parameters allocated through specification |
| | documents |
| | |
| 8192 - 32767 | Reserved |
| | |
| 32768 - 49151 | Free for experimentation. Signed parameters. |
| | |
| 41952 - 61439 | Reserved |
| | |
| 61440 - 62463 | Signatures and (signed) MACs |
| | |
| 62464 - 63487 | Parameters that are neither signed nor MACed |
| | |
| 63488 - 64511 | Rendezvous and relaying |
| | |
| 64512 - 65023 | Parameters that are neither signed nor MACed |
| | |
| 65024 - 65535 | Reserved |
+---------------+---------------------------------------------------+
The process for defining new parameters is described in Section 5.2.2
of this document.
The range between 32768 (2^15) and 49151 (2^15 + 2^14) are free for
experimentation. Types from this range SHOULD be selected in a
random fashion to reduce the probability of collisions.
5.2.1. TLV Format 5.2.1. TLV Format
The TLV-encoded parameters are described in the following The TLV-encoded parameters are described in the following
subsections. The type-field value also describes the order of these subsections. The type-field value also describes the order of these
fields in the packet, except for type values from 2048 to 4095 which fields in the packet, 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
skipping to change at page 43, line 49 skipping to change at page 44, line 22
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 increasing order by Type code, thereby limiting
the order of parameters (see Section 5.2.1). 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. between critical and non-critical parameters. Hence, even
parameter type numbers indicate non-critical parameters while odd
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 recipient ignoring
it would cause security problems. In general, new parameters it would cause security problems. In general, new parameters
SHOULD be defined as non-critical, and expect a reply from the SHOULD be defined as non-critical, and expect a reply from the
recipient. 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
skipping to change at page 47, line 29 skipping to change at page 48, line 29
Type 513 Type 513
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
Padding Padding
Group ID defines values for p and g Group ID defines values for p and g
Public Value length of the following Public Value in octets Public Value length of the following Public Value in octets
Length Length
Public Value the sender's public Diffie-Hellman key Public Value the sender's public Diffie-Hellman key
The following Group IDs have been defined: 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 random ECP group 7 [Appendix D, draft-mcgrew-fundamental-ecc-02.txt] 160-bit rnd. ECP grp 7 [App. D,draft-mcgrew-fundamental-ecc-02.txt]
256-bit random ECP group 8 [RFC4753, draft-mcgrew-fundamental-ecc-02.txt] 256-bit rnd. ECP grp 8 [RFC4753,draft-mcgrew-fundamental-ecc-02.txt]
384-bit random ECP group 9 [RFC4753, draft-mcgrew-fundamental-ecc-02.txt] 384-bit rnd. ECP grp 9 [RFC4753,draft-mcgrew-fundamental-ecc-02.txt]
521-bit random ECP group 10 [RFC4753, draft-mcgrew-fundamental-ecc-02.txt] 521-bit rnd. ECP grp 10[RFC4753,draft-mcgrew-fundamental-ecc-02.txt]
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 [fundamental-ecc]. ECDH
group 7 is covered in Appendix D. 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.
skipping to change at page 50, line 5 skipping to change at page 51, line 5
Algorithms Values Algorithms 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 [fundamental-ecc] (RECOMMENDED)
For ECDSA the Host Identity is represented by the following fields: For ECDSA the Host Identity 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 Octect-string format [fundamental-ecc] Public Key Represented in Octet-string format [fundamental-ecc]
Required ECC Curve values are: Required ECC Curve values are:
Curve Values Curve Values
RESERVED 0 RESERVED 0
NIST-ECDSA-256 1 [RFC4754] NIST-ECDSA-256 1 [RFC4754]
NIST-ECDSA-384 2 [RFC4754] NIST-ECDSA-384 2 [RFC4754]
brainpoolP160r1 3 [RFC5639] brainpoolP160r1 3 [RFC5639]
skipping to change at page 59, line 50 skipping to change at page 60, line 50
Types in the range 0-16383 are intended for reporting errors and in Types in the range 0-16383 are intended for reporting errors and in
the range 16384-65535 for other status information. An the range 16384-65535 for other status information. An
implementation that receives a NOTIFY packet with a NOTIFICATION implementation that receives a NOTIFY packet with a NOTIFICATION
error parameter in response to a request packet (e.g., I1, I2, error parameter in response to a request packet (e.g., I1, I2,
UPDATE) SHOULD assume that the corresponding request has failed UPDATE) SHOULD assume that the corresponding request has failed
entirely. Unrecognized error types MUST be ignored except that they entirely. Unrecognized error types MUST be ignored except that they
SHOULD be logged. SHOULD be logged.
Notify payloads with status types MUST be ignored if not recognized. Notify payloads with status types MUST be ignored if not recognized.
NOTIFICATION PARAMETER - ERROR TYPES Value NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ ----- ------------------------------------ -----
UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1
Sent if the parameter type has the "critical" bit set and the Sent if the parameter type has the "critical" bit set and the
parameter type is not recognized. Notification Data contains parameter type is not recognized. Notification Data contains the
the two-octet parameter type. two-octet parameter type.
INVALID_SYNTAX 7 INVALID_SYNTAX 7
Indicates that the HIP message received was invalid because Indicates that the HIP message received was invalid because some
some type, length, or value was out of range or because the type, length, or value was out of range or because the request
request was rejected for policy reasons. To avoid a denial- was rejected for policy reasons. To avoid a denial- of-service
of-service attack using forged messages, this status may only be attack using forged messages, this status may only be returned
returned for packets whose HIP_MAC (if present) and SIGNATURE have for packets whose HIP_MAC (if present) and SIGNATURE have been
been verified. This status MUST be sent in response to any verified. This status MUST be sent in response to any error not
error not covered by one of the other status types, and should covered by one of the other status types, and should not contain
not contain details to avoid leaking information to someone details to avoid leaking information to someone probing a node.
probing a node. To aid debugging, more detailed error To aid debugging, more detailed error information SHOULD be
information SHOULD be written to a console or log. written to a console or log.
NO_DH_PROPOSAL_CHOSEN 14 NO_DH_PROPOSAL_CHOSEN 14
None of the proposed group IDs was acceptable. None of the proposed group IDs was acceptable.
INVALID_DH_CHOSEN 15 INVALID_DH_CHOSEN 15
The DH Group ID field does not correspond to one offered The DH Group ID field does not correspond to one offered
by the Responder. by the Responder.
NO_HIP_PROPOSAL_CHOSEN 16 NO_HIP_PROPOSAL_CHOSEN 16
None of the proposed HIT Suites or HIP Encryption Algorithms was None of the proposed HIT Suites or HIP Encryption Algorithms was
acceptable. acceptable.
INVALID_HIP_CIPHER_CHOSEN 17 INVALID_HIP_CIPHER_CHOSEN 17
The HIP_CIPHER Crypto ID does not correspond to The HIP_CIPHER Crypto ID does not correspond to one offered by
one offered by the Responder. the Responder.
AUTHENTICATION_FAILED 24 UNSUPPORTED_HIT_SUITE 20
Sent in response to a HIP signature failure, except when Sent in response to an I1 or R1 packet for which the HIT suite
the signature verification fails in a NOTIFY message. is not supported.
CHECKSUM_FAILED 26 AUTHENTICATION_FAILED 24
Sent in response to a HIP checksum failure. Sent in response to a HIP signature failure, except when
the signature verification fails in a NOTIFY message.
HIP_MAC_FAILED 28 CHECKSUM_FAILED 26
Sent in response to a HIP HMAC failure.
ENCRYPTION_FAILED 32 Sent in response to a HIP checksum failure.
The Responder could not successfully decrypt the HIP_MAC_FAILED 28
ENCRYPTED parameter.
INVALID_HIT 40 Sent in response to a HIP HMAC failure.
Sent in response to a failure to validate the peer's ENCRYPTION_FAILED 32
HIT from the corresponding HI.
BLOCKED_BY_POLICY 42 The Responder could not successfully decrypt the
ENCRYPTED parameter.
The Responder is unwilling to set up an association INVALID_HIT 40
for some policy reason (e.g., received HIT is NULL
and policy does not allow opportunistic mode).
SERVER_BUSY_PLEASE_RETRY 44 Sent in response to a failure to validate the peer's
HIT from the corresponding HI.
The Responder is unwilling to set up an association as it is BLOCKED_BY_POLICY 42
suffering under some kind of overload and has chosen to shed load
by rejecting the Initiator's request. The Initiator may retry;
however, the Initiator MUST find another (different) puzzle
solution for any such retries. Note that the Initiator may need
to obtain a new puzzle with a new I1/R1 exchange.
NOTIFY MESSAGES - STATUS TYPES Value The Responder is unwilling to set up an association
------------------------------ ----- for some policy reason (e.g., received HIT is NULL
and policy does not allow opportunistic mode).
I2_ACKNOWLEDGEMENT 16384 SERVER_BUSY_PLEASE_RETRY 44
The Responder has an I2 from the Initiator but had to queue the The Responder is unwilling to set up an association as it is
I2 for processing. The puzzle was correctly solved and the suffering under some kind of overload and has chosen to shed load
Responder is willing to set up an association but currently has a by rejecting the Initiator's request. The Initiator may retry;
number of I2s in the processing queue. R2 will be sent after the however, the Initiator MUST find another (different) puzzle
I2 has been processed. solution for any such retries. Note that the Initiator may need
to obtain a new puzzle with a new I1/R1 exchange.
NOTIFY MESSAGES - STATUS TYPES Value
------------------------------ -----
I2_ACKNOWLEDGEMENT 16384
The Responder has an I2 from the Initiator but had to queue the
I2 for processing. The puzzle was correctly solved and the
Responder is willing to set up an association but currently has a
number of I2s in the processing queue. R2 will be sent after the
I2 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 94, line 30 skipping to change at page 95, line 30
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, the peer's next expected in-sequence Update ID
("peer Update ID") is stored. Initially, this value is zero. Update ("peer Update ID") is stored. Initially, this value is zero. Update
ID comparisons of "less than" and "greater than" are performed with ID comparisons of "less than" and "greater than" are performed with
respect to a circular sequence number space. respect to a circular sequence number space.
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 resequencing 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.
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
receiving UPDATE packets. receiving UPDATE packets.
1. If there is no corresponding HIP association, the implementation 1. If there is no corresponding HIP association, the implementation
skipping to change at page 98, line 9 skipping to change at page 99, line 9
as low as 0. as low as 0.
Responders would need a similar ACL, representing which hosts they Responders would need a similar ACL, representing which hosts they
accept HIP exchanges, and the preferred transform and local accept HIP exchanges, and the preferred transform and local
lifetimes. Wildcarding SHOULD be supported for this ACL also. lifetimes. Wildcarding SHOULD be supported for this ACL also.
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-01 8.1. Changes from draft-ietf-hip-rfc5201-bis-02
o Added recommendation to not use puzzle I twice for the same host
to avoid identical key material.
o Revised state machine and added missing event handling.
o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT
suites.
o Revised parameter type numbers (corresponding to IANA allocations)
and added missing "free for experimentation" range to the
description.
o Clarifying note on the use of the C bit in the parameter type
numbers.
8.2. 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 100, line 5 skipping to change at page 101, line 21
o Added text about new ORCHID structure to HIT overview. o Added text about new ORCHID structure to HIT overview.
o Moved Editor role to Robert Moskowitz. o Moved Editor role to Robert Moskowitz.
o Added SHA-256 to puzzle parameter. o Added SHA-256 to puzzle parameter.
o Generalized LTRUNC to be hash-function agnostic. o Generalized LTRUNC to be hash-function agnostic.
o Added text about RHASH depending on OGA. o Added text about RHASH depending on OGA.
8.2. Changes from draft-ietf-hip-rfc5201-bis-00 8.3. 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.3. Contents of draft-ietf-hip-rfc5201-bis-00 8.4. 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 so doing, 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
skipping to change at page 103, line 36 skipping to change at page 104, line 49
bits have to be carried in the HIT. Using more bits for the HIT bits have to be carried in the HIT. Using more bits for the HIT
Suite ID reduces the cryptographic strength of the HIT. HIT Suite Suite ID reduces the cryptographic strength of the HIT. HIT Suite
IDs must be allocated carefully to avoid namespace exhaustion. IDs must be allocated carefully to avoid namespace exhaustion.
Moreover, deprecated IDs should be reused after an appropriate Moreover, deprecated IDs should be reused after an appropriate
time span. If 16 Suite IDs prove insufficient and more HIT Suite time span. If 16 Suite IDs prove insufficient and more HIT Suite
IDs are needed concurrently, more bits can be used for the HIT IDs are needed concurrently, more bits can be used for the HIT
Suite ID by using one HIT Suite ID (0) to indicate that more bits Suite ID by using one HIT Suite ID (0) to indicate that more bits
should be used. The HIT_SUITE_LIST parameter already supports should be used. The HIT_SUITE_LIST parameter already supports
8-bit HIT Suite IDs, should longer IDs be needed. Possible 8-bit HIT Suite IDs, should longer IDs be needed. Possible
extensions of the HIT Suite ID space to eight-bit and new HIT extensions of the HIT Suite ID space to eight-bit and new HIT
Suite IDs are defined through IETF Consensus. Suite IDs are defined through IETF consensus.
Parameter Type Parameter Type
The 16-bit Type field in a HIP parameter describes the type of the The 16-bit Type field in a HIP parameter describes the type of the
parameter. It is defined in Section 5.2.1. The current values parameter. It is defined in Section 5.2.1. The current values
are defined in Sections 5.2.3 through 5.2.22. are defined in Sections 5.2.3 through 5.2.22.
With the exception of the assigned Type codes, the Type codes 0 With the exception of the assigned Type codes, the Type codes 0
through 1023 and 61440 through 65535 are reserved for future base through 1023 and 61440 through 65535 are reserved for future base
protocol extensions, and are assigned through IETF Consensus. protocol extensions, and are assigned through IETF Consensus.
The Type codes 32768 through 49141 are reserved for The Type codes 32768 through 49151 are reserved for
experimentation. Types SHOULD be selected in a random fashion experimentation. Types SHOULD be selected in a random fashion
from this range, thereby reducing the probability of collisions. from this range, thereby reducing the probability of collisions.
A method employing genuine randomness (such as flipping a coin) A method employing genuine randomness (such as flipping a coin)
SHOULD be used. SHOULD be used.
All other Type codes are assigned through First Come First Served, All other Type codes are assigned through First Come First Served,
with Specification Required [RFC2434]. with Specification Required [RFC2434].
Group ID Group ID
skipping to change at page 113, line 33 skipping to change at page 114, line 33
ORCHID. ORCHID.
The set of used HIT Suites will be extended to counter the progress The set of used HIT Suites will be extended to counter the progress
in computation capabilities and vulnerabilities in the employed in computation capabilities and vulnerabilities in the employed
algorithms. The intended use of the HIT Suites is to introduce a new algorithms. The intended use of the HIT Suites is to introduce a new
HIT Suite and phase out an old one before it becomes insecure. Since HIT Suite and phase out an old one before it becomes insecure. Since
the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID
0 is reserved) to be used in parallel, phased-out HIT Suites must be 0 is reserved) to be used in parallel, phased-out HIT Suites must be
reused at some point. In such a case, there will be a rollover of reused at some point. In such a case, there will be a rollover of
the HIT Suite ID and the next newly introduced HIT Suite will start the HIT Suite ID and the next newly introduced HIT Suite will start
with a lower HIT Suite index than the previoulsy introduced one. The with a lower HIT Suite index than the previously introduced one. The
rollover effectively deprecates the reused HIT Suite. For a smooth rollover effectively deprecates the reused HIT Suite. For a smooth
transition, the HIT Suite should be deprecated a considerable time transition, the HIT Suite should be deprecated a considerable time
before the HIT Suite index is reused. before the HIT Suite index is reused.
Since the number of HIT Suites is tightly limited to 16, the HIT Since the number of HIT Suites is tightly limited to 16, the HIT
Suites must be assigned carefully. Hence, sets of suitable Suites must be assigned carefully. Hence, sets of suitable
algorithms are grouped in a HIT Suite. algorithms are grouped in a HIT Suite.
The HIT Suite of the Responder's HIT determines the RHASH and the The HIT Suite of the Responder's HIT determines the RHASH and the
hash function to be used for the HMAC in HIP control packets as well hash function to be used for the HMAC in HIP control packets as well
 End of changes. 68 change blocks. 
268 lines changed or deleted 355 lines changed or added

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