draft-ietf-hip-rfc5201-bis-13.txt   draft-ietf-hip-rfc5201-bis-14.txt 
Network Working Group R. Moskowitz, Ed. Network Working Group R. Moskowitz, Ed.
Internet-Draft Verizon Internet-Draft Verizon
Obsoletes: 5201 (if approved) T. Heer Obsoletes: 5201 (if approved) T. Heer
Intended status: Standards Track Hirschmann Automation and Intended status: Standards Track Hirschmann Automation and
Expires: March 9, 2014 Control Expires: April 9, 2014 Control
P. Jokela P. Jokela
Ericsson Research NomadicLab Ericsson Research NomadicLab
T. Henderson T. Henderson
The Boeing Company The Boeing Company
September 5, 2013 October 6, 2013
Host Identity Protocol Version 2 (HIPv2) Host Identity Protocol Version 2 (HIPv2)
draft-ietf-hip-rfc5201-bis-13 draft-ietf-hip-rfc5201-bis-14
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 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 9, 2014. This Internet-Draft will expire on April 9, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 46 skipping to change at page 2, line 46
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 . . . . . . . . . . . . . . . . . . . . 25
4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . 25 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . 26
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 . . . . . . . . . . . . 35
4.5. User Data Considerations . . . . . . . . . . . . . . . . 36 4.5. User Data Considerations . . . . . . . . . . . . . . . . 37
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 . 37
4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 36 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 37
4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 36 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 37
4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 36 4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 37
4.6. Certificate Distribution . . . . . . . . . . . . . . . . 37 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 38
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 37 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 37 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 38
5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 38 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 40
5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 39 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 40
5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 39 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 40
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 40 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 41
5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 43 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 44
5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 45 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 46
5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 47
5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 49
5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 49 5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 50
5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 50 5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 51
5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 51 5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 52
5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 52 5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 54 5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 55
5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 55 5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 56
5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 56 5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 56 5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 57
5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 57 5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 58
5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 58 5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 59
5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 60 5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 61
5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 61 5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 62
5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 65 5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 66
5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 65 5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 66
5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 66 5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 67
5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 67 5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 68
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . 67 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . 68
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 68 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 69
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 69 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 70
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 72 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 73
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 73 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 74
5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 74 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 75
5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 75 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 76
5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 75 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 76
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 76 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 77
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . 76 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . 77
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 76 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 77
5.4.2. Other Problems with the HIP Header and Packet 5.4.2. Other Problems with the HIP Header and Packet
Structure . . . . . . . . . . . . . . . . . . . . . . 77 Structure . . . . . . . . . . . . . . . . . . . . . . 77
5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 77 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 78
5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 77 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 78
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 77 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 78
6.1. Processing Outgoing Application Data . . . . . . . . . . 78 6.1. Processing Outgoing Application Data . . . . . . . . . . 79
6.2. Processing Incoming Application Data . . . . . . . . . . 79 6.2. Processing Incoming Application Data . . . . . . . . . . 80
6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 80 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 81
6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 81 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 82
6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 81 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 82
6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 84 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 85
6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . 86 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . 87
6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . 87 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . 88
6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 88 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 89
6.6.2. Processing Incoming ICMP Protocol Unreachable 6.6.2. Processing Incoming ICMP Protocol Unreachable
Messages . . . . . . . . . . . . . . . . . . . . . . 89 Messages . . . . . . . . . . . . . . . . . . . . . . 90
6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 89 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 90
6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 90 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 91
6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 91 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 92
6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 91 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 92
6.8.1. Handling of Malformed Messages . . . . . . . . . . . 94 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 95
6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 94 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 95
6.9.1. Handling of Malformed Messages . . . . . . . . . . . 97 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 98
6.10. Processing of Incoming R2 Packets . . . . . . . . . . . 97 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . 98
6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 97 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 98
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 98 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 99
6.12.1. Handling a SEQ Parameter in a Received UPDATE 6.12.1. Handling a SEQ Parameter in a Received UPDATE
Message . . . . . . . . . . . . . . . . . . . . . . . 99 Message . . . . . . . . . . . . . . . . . . . . . . . 100
6.12.2. Handling an ACK Parameter in a Received UPDATE 6.12.2. Handling an ACK Parameter in a Received UPDATE
Packet . . . . . . . . . . . . . . . . . . . . . . . 100 Packet . . . . . . . . . . . . . . . . . . . . . . . 101
6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 101 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 102
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 101 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 102
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 101 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 102
6.16. Handling State Loss . . . . . . . . . . . . . . . . . . 101 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . 102
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 102 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 103
8. Security Considerations . . . . . . . . . . . . . . . . . . . 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 103
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 108
11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 108 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 109
11.1. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 108 11.1. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 109
11.2. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 109 11.2. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 110
11.3. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 109 11.3. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 110
11.4. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 109 11.4. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 110
11.5. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 109 11.5. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 110
11.6. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 109 11.6. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 110
11.7. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 109 11.7. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 110
11.8. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 110 11.8. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 111
11.9. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 110 11.9. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 111
11.10. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 112 11.10. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 113
11.11. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 112 11.11. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 113
11.12. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 113 11.12. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 114
11.13. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 115 11.13. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 116
11.14. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 115 11.14. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 116
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 115 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 116
12.1. Normative References . . . . . . . . . . . . . . . . . . 115 12.1. Normative References . . . . . . . . . . . . . . . . . . 116
12.2. Informative References . . . . . . . . . . . . . . . . . 117 12.2. Informative References . . . . . . . . . . . . . . . . . 118
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 120 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 121
Appendix B. Generating a Public Key Encoding from an HI . . . . 121 Appendix B. Generating a Public Key Encoding from an HI . . . . 122
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 122 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 123
C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 122 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 123
C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . 122 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . 123
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . 123 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . 124
Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 124 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 125
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 124 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 125
1. Introduction 1. Introduction
This document specifies the details of the Host Identity Protocol This document specifies the details of the Host Identity Protocol
(HIP). A high-level description of the protocol and the underlying (HIP). A high-level description of the protocol and the underlying
architectural thinking is available in the separate HIP architecture architectural thinking is available in the separate HIP architecture
description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP
architecture proposes an alternative to the dual use of IP addresses architecture proposes an alternative to the dual use of IP addresses
as "locators" (routing labels) and "identifiers" (endpoint, or host, as "locators" (routing labels) and "identifiers" (endpoint, or host,
identifiers). In HIP, public cryptographic keys, of a public/private identifiers). In HIP, public cryptographic keys, of a public/private
skipping to change at page 24, line 15 skipping to change at page 24, line 15
If end-to-end security is in place, then the worst that can happen in If end-to-end security is in place, then the worst that can happen in
both the opportunistic HIP and non-HIP (normal IP) cases is denial- both the opportunistic HIP and non-HIP (normal IP) cases is denial-
of-service; an entity on the path can disrupt communications, but of-service; an entity on the path can disrupt communications, but
will be unable to successfully insert itself as a man-in-the-middle. will be unable to successfully insert itself as a man-in-the-middle.
However, once the opportunistic exchange has successfully completed, However, once the opportunistic exchange has successfully completed,
HIP provides confidentiality and integrity protection for the HIP provides confidentiality and integrity protection for the
communications, and can securely change the locators of the communications, and can securely change the locators of the
endpoints. endpoints.
As a result, it is believed that the HIP opportunistic mode is at As a result, opportunistic mode in HIP offers a "better than nothing"
least as secure as current IP. security model. Initially, a base exchange authenticated in the
opportunistic mode involves a leap of faith subject to man-in-the-
middle attacks, but subsequent datagrams related to the same HIP
association cannot be compromised by a new man-in-the-middle attack,
and further, if the man-in-the-middle moves away from the path of the
active association, the attack would be exposed after the fact.
Thus, it can be stated that opportunistic mode in HIP is at least as
secure as unprotected IP-based communications.
4.2. Updating a HIP Association 4.2. Updating a HIP Association
A HIP association between two hosts may need to be updated over time. A HIP association between two hosts may need to be updated over time.
Examples include the need to rekey expiring security associations, Examples include the need to rekey expiring security associations,
add new security associations, or change IP addresses associated with add new security associations, or change IP addresses associated with
hosts. The UPDATE packet is used for those and other similar hosts. The UPDATE packet is used for those and other similar
purposes. This document only specifies the UPDATE packet format and purposes. This document only specifies the UPDATE packet format and
basic processing rules, with mandatory parameters. The actual usage basic processing rules, with mandatory parameters. The actual usage
is defined in separate specifications. is defined in separate specifications.
skipping to change at page 28, line 4 skipping to change at page 28, line 25
| Receive I2, process | If successful, send R2 and go to R2-SENT | | Receive I2, process | If successful, send R2 and go to R2-SENT |
| | | | | |
| | If fail, stay at UNASSOCIATED | | | If fail, stay at UNASSOCIATED |
| | | | | |
| Receive user data | Optionally send ICMP as defined in | | Receive user data | Optionally send ICMP as defined in |
| for an unknown HIP | Section 5.4 and stay at UNASSOCIATED | | for an unknown HIP | Section 5.4 and stay at UNASSOCIATED |
| association | | | association | |
| | | | | |
| Receive CLOSE | Optionally send ICMP Parameter Problem and | | Receive CLOSE | Optionally send ICMP Parameter Problem and |
| | stay at UNASSOCIATED | | | stay at UNASSOCIATED |
| | |
| Receive ANYOTHER | Drop and stay at UNASSOCIATED | | Receive ANYOTHER | Drop and stay at UNASSOCIATED |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 2: UNASSOCIATED - Start state Table 2: UNASSOCIATED - Start state
System behavior in state I1-SENT, Table 3. System behavior in state I1-SENT, Table 3.
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Trigger | Action | | Trigger | Action |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
skipping to change at page 38, line 16 skipping to change at page 39, line 16
than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value. than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value.
Future documents MAY define behavior for also other values. However, Future documents MAY define behavior for also other values. However,
current implementations MUST ignore trailing data if an unimplemented current implementations MUST ignore trailing data if an unimplemented
Next Header value is received. Next Header value is received.
The Header Length field contains the combined length of the HIP The Header Length field contains the combined length of the HIP
Header and HIP parameters in 8-byte units, excluding the first 8 Header and HIP parameters in 8-byte units, excluding the first 8
bytes. Since all HIP headers MUST contain the sender's and bytes. Since all HIP headers MUST contain the sender's and
receiver's HIT fields, the minimum value for this field is 4, and receiver's HIT fields, the minimum value for this field is 4, and
conversely, the maximum length of the HIP Parameters field is conversely, the maximum length of the HIP Parameters field is
(255*8)-32 = 2008 bytes. Note: this sets an additional limit for (255*8)-32 = 2008 bytes (see Section 5.1.3 regarding HIP
sizes of parameters included in the Parameters field, independent of fragmentation). Note: this sets an additional limit for sizes of
the individual parameter maximum lengths. parameters included in the Parameters field, independent of the
individual parameter maximum lengths.
The Packet Type indicates the HIP packet type. The individual packet The Packet Type indicates the HIP packet type. The individual packet
types are defined in the relevant sections. If a HIP host receives a types are defined in the relevant sections. If a HIP host receives a
HIP packet that contains an unrecognized packet type, it MUST drop HIP packet that contains an unrecognized packet type, it MUST drop
the packet. the packet.
The HIP Version field is four bits. The version defined in this The HIP Version field is four bits. The version defined in this
document is 2. The version number is expected to be incremented only document is 2. The version number is expected to be incremented only
if there are incompatible changes to the protocol. Most extensions if there are incompatible changes to the protocol. Most extensions
can be handled by defining new packet types, new parameter types, or can be handled by defining new packet types, new parameter types, or
skipping to change at page 71, line 26 skipping to change at page 72, line 26
enough precomputed R1 packets to supply each potential Initiator with enough precomputed R1 packets to supply each potential Initiator with
a different DH key, the Responder MAY send the same DH key to several a different DH key, the Responder MAY send the same DH key to several
Initiators, thereby creating the possibility of multiple legitimate Initiators, thereby creating the possibility of multiple legitimate
Initiators ending up using the same Responder-side public key. Initiators ending up using the same Responder-side public key.
However, as soon as the Responder knows that it will use a particular However, as soon as the Responder knows that it will use a particular
DH key, it SHOULD stop offering it. This design is aimed to allow DH key, it SHOULD stop offering it. This design is aimed to allow
resource-constrained Responders to offer services under I1 packet resource-constrained Responders to offer services under I1 packet
storms and to simultaneously make the probability of DH key re-use storms and to simultaneously make the probability of DH key re-use
both statistical and as low as possible. both statistical and as low as possible.
If the Responder uses the same DH keypair for multiple handshakes. If the Responder uses the same DH keypair for multiple handshakes, it
It must take care to avoid small subgroup attacks [RFC2785]. To must take care to avoid small subgroup attacks [RFC2785]. To avoid
avoid these attacks, when receiving the I2 message, the Responder these attacks, when receiving the I2 message, the Responder SHOULD
SHOULD validate the Initiators DH public key as described in validate the Initiators DH public key as described in [RFC2785]
[RFC2785] Section 3.1. In case the validation fails, the Responder Section 3.1. In case the validation fails, the Responder MUST NOT
MUST NOT generate a DH shared key and MUST silently abort the HIP generate a DH shared key and MUST silently abort the HIP BEX.
BEX.
The HIP_CIPHER contains the encryption algorithms supported by the The HIP_CIPHER contains the encryption algorithms supported by the
Responder to encrypt the contents of the ENCRYPTED parameter, in the Responder to encrypt the contents of the ENCRYPTED parameter, in the
order of preference. All implementations MUST support AES [RFC3602]. order of preference. All implementations MUST support AES [RFC3602].
The HIT_SUITE_LIST parameter is an ordered list of the Responder's The HIT_SUITE_LIST parameter is an ordered list of the Responder's
preferred and supported HIT Suites. The list allows the Initiator to preferred and supported HIT Suites. The list allows the Initiator to
determine whether its own source HIT matches any suite supported by determine whether its own source HIT matches any suite supported by
the Responder. the Responder.
skipping to change at page 90, line 40 skipping to change at page 91, line 40
6. The responder expresses its supported HIP transport formats in 6. The responder expresses its supported HIP transport formats in
the TRANSPORT_FORMAT_LIST as described in Section 5.2.11. The the TRANSPORT_FORMAT_LIST as described in Section 5.2.11. The
Responder MUST at least provide one payload transport format Responder MUST at least provide one payload transport format
type. type.
7. The Responder sends the R1 packet to the source IP address of the 7. The Responder sends the R1 packet to the source IP address of the
I1 packet. I1 packet.
6.7.1. R1 Management 6.7.1. R1 Management
All compliant implementations MUST be able to produce R1 packets. An All compliant implementations MUST be able to produce R1 packets;
R1 packet MAY be precomputed. An R1 packet MAY be reused for time even if a device is configured by policy to only initiate
Delta T, which is implementation dependent, and SHOULD be deprecated associations, it must be able to process I1s in case of recovery from
and not used once a valid response I2 packet has been received from loss of state or key exhaustion. An R1 packet MAY be precomputed.
an Initiator. During an I1 message storm, an R1 packet MAY be re- An R1 packet MAY be reused for time Delta T, which is implementation
used beyond this limit. R1 information MUST NOT be discarded until dependent, and SHOULD be deprecated and not used once a valid
Delta S after T. Time S is the delay needed for the last I2 packet response I2 packet has been received from an Initiator. During an I1
to arrive back to the Responder. message storm, an R1 packet MAY be re-used beyond this limit. R1
information MUST NOT be discarded until Delta S after T. Time S is
the delay needed for the last I2 packet to arrive back to the
Responder.
Implementations that support multiple DH groups MAY pre-compute R1 Implementations that support multiple DH groups MAY pre-compute R1
packets for each supported group so that incoming I1 packets with packets for each supported group so that incoming I1 packets with
different DH Group IDs in the DH_GROUP_LIST can be served quickly. different DH Group IDs in the DH_GROUP_LIST can be served quickly.
An implementation MAY keep state about received I1 packets and match An implementation MAY keep state about received I1 packets and match
the received I2 packets against the state, as discussed in the received I2 packets against the state, as discussed in
Section 4.1.1. Section 4.1.1.
6.7.2. Handling Malformed Messages 6.7.2. Handling Malformed Messages
skipping to change at page 115, line 33 skipping to change at page 116, line 33
[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 Version 2 (ORCHIDv2)", Hash Identifiers Version 2 (ORCHIDv2)",
draft-ietf-hip-rfc4843-bis-04 (work in draft-ietf-hip-rfc4843-bis-04 (work in
progress), May 2013. progress), May 2013.
[I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., and J. Melen, [I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., and J. Melen,
"Using the Encapsulating Security Payload "Using the Encapsulating Security Payload
(ESP) Transport Format with the Host (ESP) Transport Format with the Host
Identity Protocol (HIP)", Identity Protocol (HIP)",
draft-ietf-hip-rfc5202-bis-03 (work in draft-ietf-hip-rfc5202-bis-04 (work in
progress), July 2013. progress), September 2013.
[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. Lengths", NIST 800-131A, January 2011.
[RFC0768] Postel, J., "User Datagram Protocol", [RFC0768] Postel, J., "User Datagram Protocol",
STD 6, RFC 768, August 1980. STD 6, RFC 768, August 1980.
 End of changes. 17 change blocks. 
134 lines changed or deleted 145 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/