draft-ietf-hip-rfc5201-bis-11.txt   draft-ietf-hip-rfc5201-bis-12.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: August 29, 2013 Control Expires: January 1, 2014 Control
P. Jokela P. Jokela
Ericsson Research NomadicLab Ericsson Research NomadicLab
T. Henderson T. Henderson
The Boeing Company The Boeing Company
February 25, 2013 June 30, 2013
Host Identity Protocol Version 2 (HIPv2) Host Identity Protocol Version 2 (HIPv2)
draft-ietf-hip-rfc5201-bis-11 draft-ietf-hip-rfc5201-bis-12
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 August 29, 2013. This Internet-Draft will expire on January 1, 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 4, line 8 skipping to change at page 4, line 8
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 . . . . . . . . . . . 74
5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 74 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 75
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 . . 75 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 76
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 . . . . . . . . . . . . . . . 76 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 77
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 . . . . . . . . . . . . . . . . . . . 79 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 80
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 . . . . . . . . . . . . . . . . . . . . . . 89
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 . . . . . . . . . . . 94
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 . . . . . . . . . . . 97
6.10. Processing of Incoming R2 Packets . . . . . . . . . . . 96 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . 97
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 . . . . . . . . . . . . . . 101
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 100 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 101
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 . . . . . . . . . . . . . . . . . . . . . . . . 102
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-10 . . . . . . . 108 11.1. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 108
11.2. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 108 11.2. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 109
11.3. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 108 11.3. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 109
11.4. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 108 11.4. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 109
11.5. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 109 11.5. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 109
11.6. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 109 11.6. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 109
11.7. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 109 11.7. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 109
11.8. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 111 11.8. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 110
11.9. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 111 11.9. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 111
11.10. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 112 11.10. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 112
11.11. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 114 11.11. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 113
11.12. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 114 11.12. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 114
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 114 11.13. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 115
12.1. Normative References . . . . . . . . . . . . . . . . . . 114 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 115
12.1. Normative References . . . . . . . . . . . . . . . . . . 115
12.2. Informative References . . . . . . . . . . . . . . . . . 117 12.2. Informative References . . . . . . . . . . . . . . . . . 117
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 119 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 120
Appendix B. Generating a Public Key Encoding from an HI . . . . 120 Appendix B. Generating a Public Key Encoding from an HI . . . . 121
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 121 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 121
C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 121 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 122
C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . 121 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . 122
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . 122 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . 122
Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 123 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 123
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 123 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 123
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
skipping to change at page 69, line 47 skipping to change at page 69, line 47
DST HIT = Initiator's HIT DST HIT = Initiator's HIT
IP ( HIP ( [ R1_COUNTER, ] IP ( HIP ( [ R1_COUNTER, ]
PUZZLE, PUZZLE,
DIFFIE_HELLMAN, DIFFIE_HELLMAN,
HIP_CIPHER, HIP_CIPHER,
HOST_ID, HOST_ID,
HIT_SUITE_LIST, HIT_SUITE_LIST,
DH_GROUP_LIST, DH_GROUP_LIST,
[ ECHO_REQUEST_SIGNED, ] [ ECHO_REQUEST_SIGNED, ]
TRANSPORT_FORMAT_LIST,
HIP_SIGNATURE_2 ) HIP_SIGNATURE_2 )
<, ECHO_REQUEST_UNSIGNED >i) <, ECHO_REQUEST_UNSIGNED >i)
Valid control bits: A Valid control bits: A
If the Responder's HI is an anonymous one, the A control MUST be set. If the Responder's HI is an anonymous one, the A control MUST be set.
The Initiator's HIT MUST match the one received in the I1 packet if The Initiator's HIT MUST match the one received in the I1 packet if
the R1 is a response to an I1. If the Responder has multiple HIs, the R1 is a response to an I1. If the Responder has multiple HIs,
the Responder's HIT used MUST match Initiator's request. If the the Responder's HIT used MUST match Initiator's request. If the
Initiator used opportunistic mode, the Responder may select freely Initiator used opportunistic mode, the Responder may select freely
among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8). among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8).
The R1 packet generation counter is used to determine the currently The R1 packet generation counter is used to determine the currently
valid generation of puzzles. The value is increased periodically, valid generation of puzzles. The value is increased periodically,
skipping to change at page 71, line 47 skipping to change at page 71, line 50
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 TRANSPORT_FORMAT_LIST parameter is an ordered list of the
Responder's preferred and supported transport format types. The list
allows the Initiator and the Responder to agree on a common type for
payload protection. This parameter is described in Section 5.2.11.
The signature is calculated over the whole HIP packet as described in The signature is calculated over the whole HIP packet as described in
Section 5.2.15. This allows the Responder to use precomputed R1s. Section 5.2.15. This allows the Responder to use precomputed R1s.
The Initiator SHOULD validate this signature. It MUST check that the The Initiator SHOULD validate this signature. It MUST check that the
Responder's HI matches with the one expected, if any. Responder's HI matches with the one expected, if any.
5.3.3. I2 - the Second HIP Initiator Packet 5.3.3. I2 - the Second HIP Initiator Packet
The HIP header values for the I2 packet: The HIP header values for the I2 packet:
Header: Header:
Type = 3 Type = 3
SRC HIT = Initiator's HIT SRC HIT = Initiator's HIT
DST HIT = Responder's HIT DST HIT = Responder's HIT
IP ( HIP ( [R1_COUNTER,] IP ( HIP ( [R1_COUNTER,]
SOLUTION, SOLUTION,
DIFFIE_HELLMAN, DIFFIE_HELLMAN,
HIP_CIPHER, HIP_CIPHER,
ENCRYPTED { HOST_ID } or HOST_ID, ENCRYPTED { HOST_ID } or HOST_ID,
[ ECHO_RESPONSE_SIGNED ,] [ ECHO_RESPONSE_SIGNED ,]
TRANSPORT_FORMAT_LIST,
HIP_MAC, HIP_MAC,
HIP_SIGNATURE HIP_SIGNATURE
<, ECHO_RESPONSE_UNSIGNED>i ) ) <, ECHO_RESPONSE_UNSIGNED>i ) )
Valid control bits: A Valid control bits: A
The HITs used MUST match the ones used in the R1. The HITs used MUST match the ones used in the R1.
If the Initiator's HI is an anonymous one, the A control MUST be set. If the Initiator's HI is an anonymous one, the A control MUST be set.
skipping to change at page 73, line 6 skipping to change at page 73, line 14
Responder in the R1. All implementations MUST support AES [RFC3602]. Responder in the R1. All implementations MUST support AES [RFC3602].
The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption
algorithm. The keying material is derived from the Diffie-Hellman algorithm. The keying material is derived from the Diffie-Hellman
exchanged as defined in Section 6.5. exchanged as defined in Section 6.5.
The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the
unmodified Opaque data copied from the corresponding echo request unmodified Opaque data copied from the corresponding echo request
parameter(s). parameter(s).
The TRANSPORT_FORMAT_LIST contains the single transport format type
selected by the Initiator. The chosen type MUST correspond to one of
the types offered by the Responder in the R1. Currently, the only
transport format defined is the ESP transport format
([I-D.ietf-hip-rfc5202-bis]).
The HMAC value in the HIP_MAC parameter is calculated over the whole The HMAC value in the HIP_MAC parameter is calculated over the whole
HIP packet, excluding any parameters after the HIP_MAC, as described HIP packet, excluding any parameters after the HIP_MAC, as described
in Section 6.4.1. The Responder MUST validate the HIP_MAC. in Section 6.4.1. The Responder MUST validate the HIP_MAC.
The signature is calculated over the whole HIP packet, excluding any The signature is calculated over the whole HIP packet, excluding any
parameters after the HIP_SIGNATURE, as described in Section 5.2.14. parameters after the HIP_SIGNATURE, as described in Section 5.2.14.
The Responder MUST validate this signature. The Responder uses the The Responder MUST validate this signature. The Responder uses the
HI in the packet or a HI acquired by some other means for verifying HI in the packet or a HI acquired by some other means for verifying
the signature. the signature.
skipping to change at page 90, line 25 skipping to change at page 90, line 31
I1 packet, it sends an R1 with any suitable DH public key. I1 packet, it sends an R1 with any suitable DH public key.
5. If the received Responder's HIT in the I1 is NULL, the Responder 5. If the received Responder's HIT in the I1 is NULL, the Responder
selects a HIT with a the same HIT Suite as the Initiator's HIT. selects a HIT with a the same HIT Suite as the Initiator's HIT.
If this HIT Suite is not supported by the Responder, it SHOULD If this HIT Suite is not supported by the Responder, it SHOULD
select a REQUIRED HIT Suite from Section 5.2.10, which is select a REQUIRED HIT Suite from Section 5.2.10, which is
currently RSA/DSA/SHA-256. Other than that, selecting the HIT is currently RSA/DSA/SHA-256. Other than that, selecting the HIT is
a local policy matter. a local policy matter.
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.10. 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. An
R1 packet MAY be precomputed. An R1 packet MAY be reused for time R1 packet MAY be precomputed. An R1 packet MAY be reused for time
skipping to change at page 95, line 47 skipping to change at page 96, line 7
11. The encrypted HOST_ID is decrypted by the Initiator's encryption 11. The encrypted HOST_ID is decrypted by the Initiator's encryption
key defined in Section 6.5. If the decrypted data is not a key defined in Section 6.5. If the decrypted data is not a
HOST_ID parameter, the I2 packet is silently dropped. HOST_ID parameter, the I2 packet is silently dropped.
12. The implementation SHOULD also verify that the Initiator's HIT 12. The implementation SHOULD also verify that the Initiator's HIT
in the I2 packet corresponds to the Host Identity sent in the I2 in the I2 packet corresponds to the Host Identity sent in the I2
packet. (Note: some middleboxes may not able to make this packet. (Note: some middleboxes may not able to make this
verification.) verification.)
13. The system MUST verify the HIP_MAC according to the procedures 13. The system MUST process the TRANSPORT_FORMAT_LIST parameter.
Other documents specifying transport formats (e.g.
[I-D.ietf-hip-rfc5202-bis]) contain specifications for handling
any specific transport selected.
14. The system MUST verify the HIP_MAC according to the procedures
in Section 5.2.12. in Section 5.2.12.
14. The system MUST verify the HIP_SIGNATURE according to 15. The system MUST verify the HIP_SIGNATURE according to
Section 5.2.14 and Section 5.3.3. Section 5.2.14 and Section 5.3.3.
15. If the checks above are valid, then the system proceeds with 16. If the checks above are valid, then the system proceeds with
further I2 processing; otherwise, it discards the I2 and its further I2 processing; otherwise, it discards the I2 and its
state machine remains in the same state. state machine remains in the same state.
16. The I2 packet may have the A bit set -- in this case, the system 17. The I2 packet may have the A bit set -- in this case, the system
MAY choose to refuse it by dropping the I2 and the state machine MAY choose to refuse it by dropping the I2 and the state machine
returns to state UNASSOCIATED. If the A bit is set, the returns to state UNASSOCIATED. If the A bit is set, the
Initiator's HIT is anonymous and should not be stored Initiator's HIT is anonymous and should not be stored
permanently. permanently.
17. The system initializes the remaining variables in the associated 18. The system initializes the remaining variables in the associated
state, including Update ID counters. state, including Update ID counters.
18. Upon successful processing of an I2 message when the system's 19. Upon successful processing of an I2 message when the system's
state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2- state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2-
SENT, an R2 packet is sent and the system's state machine SENT, an R2 packet is sent and the system's state machine
transitions to state R2-SENT. transitions to state R2-SENT.
19. Upon successful processing of an I2 packet when the system's 20. Upon successful processing of an I2 packet when the system's
state machine is in state ESTABLISHED, the old HIP association state machine is in state ESTABLISHED, the old HIP association
is dropped and a new one is installed, an R2 packet is sent, and is dropped and a new one is installed, an R2 packet is sent, and
the system's state machine transitions to R2-SENT. the system's state machine transitions to R2-SENT.
20. Upon the system's state machine transitioning to R2-SENT, the 21. Upon the system's state machine transitioning to R2-SENT, the
system starts a timer. The state machine transitions to system starts a timer. The state machine transitions to
ESTABLISHED if some data has been received on the incoming HIP ESTABLISHED if some data has been received on the incoming HIP
association, or an UPDATE packet has been received (or some association, or an UPDATE packet has been received (or some
other packet that indicates that the peer system's state machine other packet that indicates that the peer system's state machine
has moved to ESTABLISHED). If the timer expires (allowing for has moved to ESTABLISHED). If the timer expires (allowing for
maximal amount of retransmissions of I2 packets), the state maximal amount of retransmissions of I2 packets), the state
machine transitions to ESTABLISHED. machine transitions to ESTABLISHED.
6.9.1. Handling of Malformed Messages 6.9.1. Handling of Malformed Messages
skipping to change at page 108, line 19 skipping to change at page 108, line 44
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-10 11.1. Changes from draft-ietf-hip-rfc5201-bis-11
o Specify that TRANSFORM_FORMAT_LIST is mandatory in R1 and I2; fix
incorrect section reference.
11.2. Changes from draft-ietf-hip-rfc5201-bis-10
o Issue 39: Text clarifying R1 counter rollover and Initiator o Issue 39: Text clarifying R1 counter rollover and Initiator
response to unexpected reset of the counter. response to unexpected reset of the counter.
11.2. Changes from draft-ietf-hip-rfc5201-bis-09 11.3. Changes from draft-ietf-hip-rfc5201-bis-09
o Editorial changes based on working group last call. o Editorial changes based on working group last call.
11.3. Changes from draft-ietf-hip-rfc5201-bis-08 11.4. Changes from draft-ietf-hip-rfc5201-bis-08
o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to
REQUIRED status REQUIRED status
o Issue 35: limiting ECC cofactor to 1 o Issue 35: limiting ECC cofactor to 1
o Changed text regarding issue 33 reusing DH values o Changed text regarding issue 33 reusing DH values
o Fix tracker issue 32 on Domain Identifier normative text o Fix tracker issue 32 on Domain Identifier normative text
11.4. Changes from draft-ietf-hip-rfc5201-bis-07 11.5. 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.5. Changes from draft-ietf-hip-rfc5201-bis-06 11.6. 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.6. Changes from draft-ietf-hip-rfc5201-bis-05 11.7. 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 48 skipping to change at page 110, line 29
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.7. Changes from draft-ietf-hip-rfc5201-bis-04 11.8. 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 111, line 12 skipping to change at page 111, line 45
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.8. Changes from draft-ietf-hip-rfc5201-bis-03 11.9. 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 48 skipping to change at page 112, line 34
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.9. Changes from draft-ietf-hip-rfc5201-bis-02 11.10. 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.10. Changes from draft-ietf-hip-rfc5201-bis-01 11.11. 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 114, line 11 skipping to change at page 114, line 48
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.11. Changes from draft-ietf-hip-rfc5201-bis-00 11.12. 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.12. Contents of draft-ietf-hip-rfc5201-bis-00 11.13. 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://
skipping to change at page 114, line 39 skipping to change at page 115, line 29
[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-02 (work in draft-ietf-hip-rfc4843-bis-02 (work in
progress), September 2012. progress), September 2012.
[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-01 (work in draft-ietf-hip-rfc5202-bis-02 (work in
progress), September 2012. progress), June 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. 43 change blocks. 
58 lines changed or deleted 81 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/