draft-ietf-hip-rfc5201-bis-09.txt   draft-ietf-hip-rfc5201-bis-10.txt 
Network Working Group R. Moskowitz, Ed. Network Working Group R. Moskowitz, Ed.
Internet-Draft Verizon Internet-Draft Verizon
Obsoletes: 5201 (if approved) T. Heer Obsoletes: 5201 (if approved) T. Heer
Intended status: Standards Track RWTH Aachen University, Intended status: Standards Track RWTH Aachen University,
Expires: January 17, 2013 Communication and Distributed Expires: May 27, 2013 Communication and Distributed
Systems Group Systems Group
P. Jokela P. Jokela
Ericsson Research NomadicLab Ericsson Research NomadicLab
T. Henderson T. Henderson
The Boeing Company The Boeing Company
July 16, 2012 November 23, 2012
Host Identity Protocol Version 2 (HIPv2) Host Identity Protocol Version 2 (HIPv2)
draft-ietf-hip-rfc5201-bis-09 draft-ietf-hip-rfc5201-bis-10
Abstract Abstract
This document specifies the details of the Host Identity Protocol This document specifies the details of the Host Identity Protocol
(HIP). HIP allows consenting hosts to securely establish and (HIP). HIP allows consenting hosts to securely establish and
maintain shared IP-layer state, allowing separation of the identifier maintain shared IP-layer state, allowing separation of the identifier
and locator roles of IP addresses, thereby enabling continuity of and locator roles of IP addresses, thereby enabling continuity of
communications across IP address changes. HIP is based on a SIGMA- communications across IP address changes. HIP is based on a SIGMA-
compliant Diffie-Hellman key exchange, using public key identifiers compliant Diffie-Hellman key exchange, using public key identifiers
from a new Host Identity namespace for mutual peer authentication. from a new Host Identity namespace for mutual peer authentication.
skipping to change at page 2, line 6 skipping to change at page 2, line 6
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 17, 2013. This Internet-Draft will expire on May 27, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
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
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
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 Identity (HI) and its Structure . . . . . . . . . . . . 10 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 10
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 11 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . 11
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . 11
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 13 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . 17 Group Negotiation . . . . . . . . . . . . . . . . . . 17
4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 18 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 18
4.1.5. Refusing a HIP Base Exchange . . . . . . . . . . . . 19 4.1.5. Refusing a HIP Base Exchange . . . . . . . . . . . . 19
4.1.6. Aborting a HIP Base Exchange . . . . . . . . . . . . 20 4.1.6. Aborting a HIP Base Exchange . . . . . . . . . . . . 20
4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 20 4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 20
4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 21 4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 21
4.2. Updating a HIP Association . . . . . . . . . . . . . . . 24 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 24
4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 24 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 24
4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 25 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . 25
4.4.1. State Machine Terminology . . . . . . . . . . . . . . 26 4.4.1. State Machine Terminology . . . . . . . . . . . . . . 26
4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 27 4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 27
4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 27 4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 27
4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 34 4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 34
4.5. User Data Considerations . . . . . . . . . . . . . . . . 36 4.5. User Data Considerations . . . . . . . . . . . . . . . . 36
4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 36 4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 36
4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 36 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 36
4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 36 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 36
4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 36 4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 36
4.6. Certificate Distribution . . . . . . . . . . . . . . . . 37 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 37
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 37 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 37
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 37 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 37
5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 38 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 38
5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 39 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 39
5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 39 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 39
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 40 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 40
5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 43 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 43
5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 45 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 45
5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46
5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48
5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 49 5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 49
5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 50 5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 50
5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 51 5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 51
5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 52 5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 54 5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 54
skipping to change at page 4, line 5 skipping to change at page 4, line 5
5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 57 5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 57
5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 58 5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 58
5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 60 5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 60
5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 61 5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 61
5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 65 5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 65
5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 65 5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 65
5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 66 5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 66
5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 67 5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 67
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 67 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . 67
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 68 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 68
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 69 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 69
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 72 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 72
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 73 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 73
5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 73 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 73
5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 75 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 74
5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 75 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 75
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 76 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 75
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 76 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . 76
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 76 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 76
5.4.2. Other Problems with the HIP Header and Packet 5.4.2. Other Problems with the HIP Header and Packet
Structure . . . . . . . . . . . . . . . . . . . . . . 76 Structure . . . . . . . . . . . . . . . . . . . . . . 76
5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 77 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 76
5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 77 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 77
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 77 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 77
6.1. Processing Outgoing Application Data . . . . . . . . . . 78 6.1. Processing Outgoing Application Data . . . . . . . . . . 78
6.2. Processing Incoming Application Data . . . . . . . . . . 79 6.2. Processing Incoming Application Data . . . . . . . . . . 79
6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 80 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 79
6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 81 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 81
6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 81 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 81
6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 84 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 84
6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 86 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . 86
6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 87 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . 87
6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 88 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 88
6.6.2. Processing Incoming ICMP Protocol Unreachable 6.6.2. Processing Incoming ICMP Protocol Unreachable
Messages . . . . . . . . . . . . . . . . . . . . . . 88 Messages . . . . . . . . . . . . . . . . . . . . . . 88
6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 89 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 89
6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 90 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 90
6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 91 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 91
6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 91 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 91
6.8.1. Handling of Malformed Messages . . . . . . . . . . . 93 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 93
6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 94 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 94
6.9.1. Handling of Malformed Messages . . . . . . . . . . . 96 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 96
6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 96 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . 96
6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 97 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 97
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 98 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 98
6.12.1. Handling a SEQ Parameter in a Received UPDATE 6.12.1. Handling a SEQ Parameter in a Received UPDATE
Message . . . . . . . . . . . . . . . . . . . . . . . 99 Message . . . . . . . . . . . . . . . . . . . . . . . 99
6.12.2. Handling an ACK Parameter in a Received UPDATE 6.12.2. Handling an ACK Parameter in a Received UPDATE
Packet . . . . . . . . . . . . . . . . . . . . . . . 100 Packet . . . . . . . . . . . . . . . . . . . . . . . 100
6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 100 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 100
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 100 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 100
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 101 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 101
6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 101 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . 101
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 101 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 101
8. Security Considerations . . . . . . . . . . . . . . . . . . . 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 102
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107
11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 108 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 108
11.1. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 108 11.1. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 108
11.2. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 108 11.2. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 108
11.3. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 108 11.3. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 108
11.4. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 109 11.4. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 108
11.5. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 110 11.5. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 109
11.6. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 111 11.6. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 109
11.7. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 111 11.7. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 111
11.8. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 113 11.8. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 111
11.9. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . . 113 11.9. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 112
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 113 11.10. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 114
12.1. Normative References . . . . . . . . . . . . . . . . . . 113 11.11. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 114
12.2. Informative References . . . . . . . . . . . . . . . . . 116 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 114
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 118 12.1. Normative References . . . . . . . . . . . . . . . . . . 114
12.2. Informative References . . . . . . . . . . . . . . . . . 117
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 119
Appendix B. Generating a Public Key Encoding from an HI . . . . 120 Appendix B. Generating a Public Key Encoding from an HI . . . . 120
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 120 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 120
C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 121 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 121
C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 121 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . 121
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 121 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . 122
Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 122 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 122
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 122 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 122
1. Introduction 1. Introduction
This document specifies the details of the Host Identity Protocol This document specifies the details of the Host Identity Protocol
(HIP). A high-level description of the protocol and the underlying (HIP). A high-level description of the protocol and the underlying
architectural thinking is available in the separate HIP architecture architectural thinking is available in the separate HIP architecture
description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP
architecture proposes an alternative to the dual use of IP addresses architecture proposes an alternative to the dual use of IP addresses
skipping to change at page 32, line 38 skipping to change at page 32, line 38
| | | | | |
| | If fail, stay at CLOSING | | | If fail, stay at CLOSING |
| | | | | |
| Receive CLOSE_ACK, | If successful, discard state and go to | | Receive CLOSE_ACK, | If successful, discard state and go to |
| process | UNASSOCIATED | | process | UNASSOCIATED |
| | | | | |
| | If fail, stay at CLOSING | | | If fail, stay at CLOSING |
| | | | | |
| Receive ANYOTHER | Drop and stay at CLOSING | | Receive ANYOTHER | Drop and stay at CLOSING |
| | | | | |
| Timeout | Increment timeout sum and reset timer. If | | Timeout | Increment timeout sum and reset timer. If |
| | timeout sum is less than UAL+MSL minutes, | | | timeout sum is less than UAL+MSL minutes, |
| | retransmit CLOSE and stay at CLOSING | | | retransmit CLOSE and stay at CLOSING |
| | | | | |
| | If timeout sum is greater than UAL+MSL | | | If timeout sum is greater than UAL+MSL |
| | minutes, go to UNASSOCIATED | | | minutes, go to UNASSOCIATED |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 7: CLOSING - HIP association has not been used for UAL minutes Table 7: CLOSING - HIP association has not been used for UAL minutes
System behavior in state CLOSED, Table 8. System behavior in state CLOSED, Table 8.
skipping to change at page 33, 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 (Figure 2) shows the major state transitions. The following diagram (Figure 2) shows the major state transitions.
Transitions based on received packets implicitly assume that the Transitions based on received packets implicitly assume that the
packets are successfully authenticated or processed. packets are successfully authenticated or processed.
skipping to change at page 37, line 17 skipping to change at page 37, line 17
If the host, that apparently has lost its state, decides to restart If the host, that apparently has lost its state, decides to restart
the HIP base exchange, it sends an I1 packet to the peer. After the the HIP base exchange, it sends an I1 packet to the peer. After the
base exchange has been completed successfully, the Initiator can base exchange has been completed successfully, the Initiator can
create a new HIP association and the peer drops its old payload create a new HIP association and the peer drops its old payload
associations and creates a new one. associations and creates a new one.
4.6. Certificate Distribution 4.6. Certificate Distribution
This document does not define how to use certificates or how to This document does not define how to use certificates or how to
transfer them between hosts. These functions are expected to be transfer them between hosts. These functions are expected to be
defined in a future specification as for HIP Version 1 defined in a future specification as for HIP Version 1 [RFC6253]. A
[I-D.ietf-hip-cert]. A parameter type value, meant to be used for parameter type value, meant to be used for carrying certificates, is
carrying certificates, is reserved, though: CERT, Type 768; see reserved, though: CERT, Type 768; see Section 5.2.
Section 5.2.
5. Packet Formats 5. Packet Formats
5.1. Payload Format 5.1. Payload Format
All HIP packets start with a fixed header. All HIP packets start with a fixed header.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 40, line 15 skipping to change at page 40, line 15
packet, support for path MTU discovery does not bring any value to packet, support for path MTU discovery does not bring any value to
HIP in IPv4 networks. HIP-aware NAT devices SHOULD perform IPv4 HIP in IPv4 networks. HIP-aware NAT devices SHOULD perform IPv4
reassembly/fragmentation for HIP control packets. reassembly/fragmentation for HIP control packets.
All HIP implementations have to be careful while employing a All HIP implementations have to be careful while employing a
reassembly algorithm so that the algorithm is sufficiently resistant reassembly algorithm so that the algorithm is sufficiently resistant
to DoS attacks. to DoS attacks.
Certificate chains can cause the packet to be fragmented and Certificate chains can cause the packet to be fragmented and
fragmentation can open implementations to denial-of-service attacks fragmentation can open implementations to denial-of-service attacks
[KAU03]. "Hash and URL" schemes as defined in [I-D.ietf-hip-cert] [KAU03]. "Hash and URL" schemes as defined in [RFC6253] for HIP
for HIP version 1 may be used to avoid fragmentation and mitigate version 1 may be used to avoid fragmentation and mitigate resulting
resulting DoS attacks. DoS attacks.
5.2. HIP Parameters 5.2. HIP Parameters
The HIP parameters carry information that is necessary for The HIP parameters carry information that is necessary for
establishing and maintaining a HIP association. For example, the establishing and maintaining a HIP association. For example, the
peer's public keys as well as the signaling for negotiating ciphers peer's public keys as well as the signaling for negotiating ciphers
and payload handling are encapsulated in HIP parameters. Additional and payload handling are encapsulated in HIP parameters. Additional
information, meaningful for end-hosts or middleboxes, may also be information, meaningful for end-hosts or middleboxes, may also be
included in HIP parameters. The specification of the HIP parameters included in HIP parameters. The specification of the HIP parameters
and their mapping to HIP packets and packet types is flexible to and their mapping to HIP packets and packet types is flexible to
skipping to change at page 42, line 27 skipping to change at page 42, line 27
| | | numbers | | | | | numbers | |
| | | | | | | | | |
| HIP_MAC | 61505 | variable | HMAC-based message | | HIP_MAC | 61505 | variable | HMAC-based message |
| | | | authentication code, | | | | | authentication code, |
| | | | with key material | | | | | with key material |
| | | | from KEYMAT | | | | | from KEYMAT |
| | | | | | | | | |
| HIP_MAC_2 | 61569 | variable | HMAC based message | | HIP_MAC_2 | 61569 | variable | HMAC based message |
| | | | authentication code, | | | | | authentication code, |
| | | | with key material | | | | | with key material |
| | | | from KEYMAT. Unlike | | | | | from KEYMAT. Unlike |
| | | | HIP_MAC, the HOST_ID | | | | | HIP_MAC, the HOST_ID |
| | | | parameter is | | | | | parameter is |
| | | | included in | | | | | included in |
| | | | HIP_MAC_2 | | | | | HIP_MAC_2 |
| | | | calculation. | | | | | calculation. |
| | | | | | | | | |
| HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 | | HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 |
| | | | packet | | | | | packet |
| | | | | | | | | |
| HIP_SIGNATURE | 61697 | variable | Signature of the | | HIP_SIGNATURE | 61697 | variable | Signature of the |
skipping to change at page 43, line 22 skipping to change at page 43, line 22
| | | | | |
| 1024 - 2047 | Reserved | | 1024 - 2047 | Reserved |
| | | | | |
| 2048 - 4095 | Parameters related to HIP transport formats | | 2048 - 4095 | Parameters related to HIP transport formats |
| | | | | |
| 4096 - 8191 | Signed parameters allocated through specification | | 4096 - 8191 | Signed parameters allocated through specification |
| | documents | | | documents |
| | | | | |
| 8192 - 32767 | Reserved | | 8192 - 32767 | Reserved |
| | | | | |
| 32768 - 49151 | Free for experimentation. Signed parameters. | | 32768 - 49151 | Free for experimentation. Signed parameters. |
| | | | | |
| 41952 - 61439 | Reserved | | 41952 - 61439 | Reserved |
| | | | | |
| 61440 - 64443 | Signatures and (signed) MACs | | 61440 - 64443 | Signatures and (signed) MACs |
| | | | | |
| 62464 - 63487 | Parameters that are neither signed nor MACed | | 62464 - 63487 | Parameters that are neither signed nor MACed |
| | | | | |
| 63488 - 64511 | Rendezvous and relaying | | 63488 - 64511 | Rendezvous and relaying |
| | | | | |
| 64512 - 65023 | Parameters that are neither signed nor MACed | | 64512 - 65023 | Parameters that are neither signed nor MACed |
skipping to change at page 71, line 47 skipping to change at page 71, line 47
determine whether its own source HIT matches any suite supported by determine whether its own source HIT matches any suite supported by
the Responder. the Responder.
The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain
data that the sender wants to receive unmodified in the corresponding data that the sender wants to receive unmodified in the corresponding
response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED
parameter. The R1 packet may contain zero or more parameter. The R1 packet may contain zero or more
ECHO_REQUEST_UNSIGNED parameters as described in Section ECHO_REQUEST_UNSIGNED parameters as described in Section
Section 5.2.21. Section 5.2.21.
The signature is calculated over the whole HIP packet, after setting The signature is calculated over the whole HIP packet as described in
the Initiator's HIT, header checksum, as well as the Opaque field and
the Random #I in the PUZZLE parameter temporarily to zero, and
excluding any parameters that follow the signature, as described in
Section 5.2.15. This allows the Responder to use precomputed R1s. Section 5.2.15. This allows the Responder to use precomputed R1s.
The Initiator SHOULD validate this signature. It MUST check that the The Initiator SHOULD validate this signature. It MUST check that the
Responder's HI matches with the one expected, if any. Responder's HI matches with the one expected, if any.
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
skipping to change at page 108, line 19 skipping to change at page 108, line 19
changes were introduced through the working group process. Most changes were introduced through the working group process. Most
notably, the original document was split in two, one containing the notably, the original document was split in two, one containing the
base exchange and the other one defining how to use ESP. Some base exchange and the other one defining how to use ESP. Some
modifications to the protocol proposed by Aura, et al., [AUR03] were modifications to the protocol proposed by Aura, et al., [AUR03] were
added at a later stage. added at a later stage.
11. Changes from RFC 5201 11. Changes from RFC 5201
This section summarizes the changes made from [RFC5201]. This section summarizes the changes made from [RFC5201].
11.1. Changes from draft-ietf-hip-rfc5201-bis-07 11.1. Changes from draft-ietf-hip-rfc5201-bis-09
o Editorial changes based on working group last call.
11.2. Changes from draft-ietf-hip-rfc5201-bis-08
o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to
REQUIRED status
o Issue 35: limiting ECC cofactor to 1
o Changed text regarding issue 33 reusing DH values
o Fix tracker issue 32 on Domain Identifier normative text
11.3. Changes from draft-ietf-hip-rfc5201-bis-07
o Removed lingering references to SHA-1 as the mandatory hash o Removed lingering references to SHA-1 as the mandatory hash
algorithm (which was changed to SHA-256 in the -02 draft version). algorithm (which was changed to SHA-256 in the -02 draft version).
o For parameter type number changes, changed "IETF Review" to "IETF o For parameter type number changes, changed "IETF Review" to "IETF
Review or IESG Approval". Review or IESG Approval".
o Updated Appendix C checksum examples to conform to HIPv2 packets. o Updated Appendix C checksum examples to conform to HIPv2 packets.
11.2. Changes from draft-ietf-hip-rfc5201-bis-06 11.4. Changes from draft-ietf-hip-rfc5201-bis-06
o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains
an R1_COUNTER. This required to make the R1 counter a critical an R1_COUNTER. This required to make the R1 counter a critical
parameter. Hence, the parameter type number of the R1_COUNTER parameter. Hence, the parameter type number of the R1_COUNTER
changed from 128 to 129. changed from 128 to 129.
o Made KDF dependent on DH Group to enable negotiation of the KDF. o Made KDF dependent on DH Group to enable negotiation of the KDF.
11.3. Changes from draft-ietf-hip-rfc5201-bis-05 11.5. Changes from draft-ietf-hip-rfc5201-bis-05
o Changed type number of DH_GROUP_LIST from 2151 to 511 because it o Changed type number of DH_GROUP_LIST from 2151 to 511 because it
was in the number space that is reserved for the HIP transport was in the number space that is reserved for the HIP transport
mode negotiations. mode negotiations.
o Added transport form type list parameter. Transport forms are now o Added transport form type list parameter. Transport forms are now
negotiated with this list instead of by their order in the HIP negotiated with this list instead of by their order in the HIP
packet. This allows to remove the exception of the transport packet. This allows to remove the exception of the transport
format parameters that were ordered by their preference instead of format parameters that were ordered by their preference instead of
by their type number. This should remove complexity from by their type number. This should remove complexity from
skipping to change at page 109, line 26 skipping to change at page 109, line 41
o Permit using Anonymous HI control in packets other than R1/I2. o Permit using Anonymous HI control in packets other than R1/I2.
o Fixed minor reference error (RFC2418, RFC2410). o Fixed minor reference error (RFC2418, RFC2410).
o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable
via the UI. via the UI.
o Editorial changes. o Editorial changes.
11.4. Changes from draft-ietf-hip-rfc5201-bis-04 11.6. Changes from draft-ietf-hip-rfc5201-bis-04
o Clarifications of the Security Considerations section. One DoS o Clarifications of the Security Considerations section. One DoS
defense mechanism was changed to be more effective and less prone defense mechanism was changed to be more effective and less prone
to misuse. to misuse.
o Minor clarifications of the state machine. o Minor clarifications of the state machine.
o Clarified text on HIP puzzle. o Clarified text on HIP puzzle.
o Added names and references for figures. o Added names and references for figures.
skipping to change at page 110, line 39 skipping to change at page 111, line 7
o Changed IETF Consensus to IETF Review or IESG Approval in IANA o Changed IETF Consensus to IETF Review or IESG Approval in IANA
section. section.
o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K
throughout the document. throughout the document.
o Updated references. o Updated references.
o Editorial changes. o Editorial changes.
11.5. Changes from draft-ietf-hip-rfc5201-bis-03 11.7. Changes from draft-ietf-hip-rfc5201-bis-03
o Editorial changes to improve clarity and readability. o Editorial changes to improve clarity and readability.
o Removed obsoleted (not applicable) attack from security o Removed obsoleted (not applicable) attack from security
consideration section. consideration section.
o Added a requirement that hosts MUST support processing of ACK o Added a requirement that hosts MUST support processing of ACK
parameters with several SEQ numbers even when they do not support parameters with several SEQ numbers even when they do not support
sending such parameters. sending such parameters.
skipping to change at page 111, line 26 skipping to change at page 111, line 43
o Clarified the use of HITs in opportunistic mode. o Clarified the use of HITs in opportunistic mode.
o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as
between SIGNATURE and SIGNATURE_2. between SIGNATURE and SIGNATURE_2.
o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to
RESPONDER_BUSY_PLEASE_RETRY. RESPONDER_BUSY_PLEASE_RETRY.
o Mentioned that there are multiple valid puzzle solutions. o Mentioned that there are multiple valid puzzle solutions.
11.6. Changes from draft-ietf-hip-rfc5201-bis-02 11.8. Changes from draft-ietf-hip-rfc5201-bis-02
o Added recommendation to not use puzzle #I twice for the same host o Added recommendation to not use puzzle #I twice for the same host
to avoid identical key material. to avoid identical key material.
o Revised state machine and added missing event handling. o Revised state machine and added missing event handling.
o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT
suites. suites.
o Revised parameter type numbers (corresponding to IANA allocations) o Revised parameter type numbers (corresponding to IANA allocations)
and added missing "free for experimentation" range to the and added missing "free for experimentation" range to the
description. description.
o Clarifying note on the use of the C bit in the parameter type o Clarifying note on the use of the C bit in the parameter type
numbers. numbers.
11.7. Changes from draft-ietf-hip-rfc5201-bis-01 11.9. 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)
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 Included HIT_SUITEs. o Included HIT_SUITEs.
o Added DH negotiation to I1 and R1. o Added DH negotiation to I1 and R1.
skipping to change at page 113, line 38 skipping to change at page 114, line 7
o Added text about new ORCHID structure to HIT overview. o Added text about new ORCHID structure to HIT overview.
o Moved Editor role to Robert Moskowitz. o Moved Editor role to Robert Moskowitz.
o Added SHA-256 to puzzle parameter. o Added SHA-256 to puzzle parameter.
o Generalized LTRUNC to be hash-function agnostic. o Generalized LTRUNC to be hash-function agnostic.
o Added text about RHASH depending on OGA. o Added text about RHASH depending on OGA.
11.8. Changes from draft-ietf-hip-rfc5201-bis-00 11.10. Changes from draft-ietf-hip-rfc5201-bis-00
o Added reasoning why BIS document is needed. o Added reasoning why BIS document is needed.
11.9. Contents of draft-ietf-hip-rfc5201-bis-00 11.11. Contents of draft-ietf-hip-rfc5201-bis-00
o RFC5201 was submitted as draft-RFC. o RFC5201 was submitted as draft-RFC.
12. References 12. References
12.1. Normative References 12.1. Normative References
[FIPS.180-2.2002] National Institute of Standards and [FIPS.180-2.2002] National Institute of Standards and
Technology, "Secure Hash Standard", Technology, "Secure Hash Standard",
FIPS PUB 180-2, August 2002, <http:// FIPS PUB 180-2, August 2002, <http://
csrc.nist.gov/publications/fips/ csrc.nist.gov/publications/fips/
fips180-2/fips180-2.pdf>. fips180-2/fips180-2.pdf>.
[I-D.ietf-hip-rfc4843-bis] Laganier, J. and F. Dupont, "An IPv6 [I-D.ietf-hip-rfc4843-bis] Laganier, J. and F. Dupont, "An IPv6
Prefix for Overlay Routable Cryptographic Prefix for Overlay Routable Cryptographic
Hash Identifiers (ORCHID)", Hash Identifiers Version 2 (ORCHIDv2)",
draft-ietf-hip-rfc4843-bis-00 (work in draft-ietf-hip-rfc4843-bis-02 (work in
progress), August 2010. progress), September 2012.
[I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., Nikander, P., [I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., and J. Melen,
and J. Melen, "Using the Encapsulating "Using the Encapsulating Security Payload
Security Payload (ESP) Transport Format (ESP) Transport Format with the Host
with the Host Identity Protocol (HIP)", Identity Protocol (HIP)",
draft-ietf-hip-rfc5202-bis-00 (work in draft-ietf-hip-rfc5202-bis-01 (work in
progress), September 2010. progress), September 2012.
[NIST.800-131A.2011] National Institute of Standards and [NIST.800-131A.2011] National Institute of Standards and
Technology, "Transitions: Recommendation Technology, "Transitions: Recommendation
for Transitioning the Use of for Transitioning the Use of
Cryptographic Algorithms and Key Cryptographic Algorithms and Key
Lengths", NIST 800-131A, January 2011, <h Lengths", NIST 800-131A, January 2011.
ttp://csrc.nist.gov/publications/
nistpubs/800-131A/sp800-131A.pdf>.
[RFC0768] Postel, J., "User Datagram Protocol", [RFC0768] Postel, J., "User Datagram Protocol",
STD 6, RFC 768, August 1980. STD 6, RFC 768, August 1980.
[RFC1035] Mockapetris, P., "Domain names - [RFC1035] Mockapetris, P., "Domain names -
implementation and specification", implementation and specification",
STD 13, RFC 1035, November 1987. STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs [RFC2119] Bradner, S., "Key words for use in RFCs
to Indicate Requirement Levels", BCP 14, to Indicate Requirement Levels", BCP 14,
skipping to change at page 117, line 20 skipping to change at page 117, line 36
(AES)", FIPS PUB 197, November 2001, <htt (AES)", FIPS PUB 197, November 2001, <htt
p://csrc.nist.gov/publications/fips/ p://csrc.nist.gov/publications/fips/
fips197/fips-197.pdf>. fips197/fips-197.pdf>.
[I-D.ietf-btns-c-api] Richardson, M., Williams, N., Komu, M., [I-D.ietf-btns-c-api] Richardson, M., Williams, N., Komu, M.,
and S. Tarkoma, "C-Bindings for IPsec and S. Tarkoma, "C-Bindings for IPsec
Application Programming Interfaces", Application Programming Interfaces",
draft-ietf-btns-c-api-04 (work in draft-ietf-btns-c-api-04 (work in
progress), March 2009. progress), March 2009.
[I-D.ietf-hip-cert] Heer, T. and S. Varjonen, "Host Identity
Protocol Certificates",
draft-ietf-hip-cert-09 (work in
progress), January 2011.
[I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol
Architecture", Architecture",
draft-ietf-hip-rfc4423-bis-02 (work in draft-ietf-hip-rfc4423-bis-05 (work in
progress), February 2011. progress), September 2012.
[I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host
Identity Protocol (HIP) Rendezvous Identity Protocol (HIP) Rendezvous
Extension", draft-ietf-hip-rfc5204-bis-00 Extension", draft-ietf-hip-rfc5204-bis-02
(work in progress), August 2010. (work in progress), September 2012.
[I-D.ietf-hip-rfc5205-bis] Laganier, J., "Host Identity Protocol [I-D.ietf-hip-rfc5205-bis] Laganier, J., "Host Identity Protocol
(HIP) Domain Name System (DNS) (HIP) Domain Name System (DNS)
Extension", draft-ietf-hip-rfc5205-bis-00 Extension", draft-ietf-hip-rfc5205-bis-02
(work in progress), August 2010. (work in progress), September 2012.
[I-D.ietf-hip-rfc5206-bis] Nikander, P., Henderson, T., Vogt, C., [I-D.ietf-hip-rfc5206-bis] Henderson, T., Vogt, C., and J. Arkko,
and J. Arkko, "Host Mobility with the "Host Mobility with the Host Identity
Host Identity Protocol", Protocol", draft-ietf-hip-rfc5206-bis-04
draft-ietf-hip-rfc5206-bis-01 (work in (work in progress), July 2012.
progress), October 2010.
[KAU03] Kaufman, C., Perlman, R., and B. [KAU03] Kaufman, C., Perlman, R., and B.
Sommerfeld, "DoS protection for UDP-based Sommerfeld, "DoS protection for UDP-based
protocols", ACM Conference on Computer protocols", ACM Conference on Computer
and Communications Security , Oct 2003. and Communications Security , Oct 2003.
[KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc'
Approach to Authenticated Diffie-Hellman Approach to Authenticated Diffie-Hellman
and Its Use in the IKE-Protocols", in and Its Use in the IKE-Protocols", in
Proceedings of CRYPTO 2003, pages 400- Proceedings of CRYPTO 2003, pages 400-
skipping to change at page 118, line 40 skipping to change at page 118, line 49
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6:
Level 3 Multihoming Shim Protocol for Level 3 Multihoming Shim Protocol for
IPv6", RFC 5533, June 2009. IPv6", RFC 5533, June 2009.
[RFC5747] Wu, J., Cui, Y., Li, X., Xu, M., and C. [RFC5747] Wu, J., Cui, Y., Li, X., Xu, M., and C.
Metz, "4over6 Transit Solution Using IP Metz, "4over6 Transit Solution Using IP
Encapsulation and MP-BGP Extensions", Encapsulation and MP-BGP Extensions",
RFC 5747, March 2010. RFC 5747, March 2010.
[RFC6253] Heer, T. and S. Varjonen, "Host Identity
Protocol Certificates", RFC 6253,
May 2011.
[SECG] SECG, "Recommended Elliptic Curve Domain [SECG] SECG, "Recommended Elliptic Curve Domain
Parameters", SEC 2 , 2000, Parameters", SEC 2 , 2000,
<http://www.secg.org/>. <http://www.secg.org/>.
Appendix A. Using Responder Puzzles Appendix A. Using Responder Puzzles
As mentioned in Section 4.1.1, the Responder may delay state creation As mentioned in Section 4.1.1, the Responder may delay state creation
and still reject most spoofed I2 packets by using a number of pre- and still reject most spoofed I2 packets by using a number of pre-
calculated R1 packets and a local selection function. This appendix calculated R1 packets and a local selection function. This appendix
defines one possible implementation in detail. The purpose of this defines one possible implementation in detail. The purpose of this
 End of changes. 53 change blocks. 
110 lines changed or deleted 119 lines changed or added

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