draft-ietf-hip-rfc5201-bis-16.txt   draft-ietf-hip-rfc5201-bis-17.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 Control Intended status: Standards Track Hirschmann Automation and Control
Expires: February 12, 2015 P. Jokela Expires: March 9, 2015 P. Jokela
Ericsson Research NomadicLab Ericsson Research NomadicLab
T. Henderson T. Henderson
University of Washington University of Washington
August 11, 2014 September 5, 2014
Host Identity Protocol Version 2 (HIPv2) Host Identity Protocol Version 2 (HIPv2)
draft-ietf-hip-rfc5201-bis-16 draft-ietf-hip-rfc5201-bis-17
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 Diffie- communications across IP address changes. HIP is based on a Diffie-
Hellman key exchange, using public key identifiers from a new Host Hellman key exchange, using public key identifiers from a new Host
Identity namespace for mutual peer authentication. The protocol is Identity namespace for mutual peer authentication. The protocol is
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 February 12, 2015. This Internet-Draft will expire on March 9, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 6 1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 6
1.2. The HIP Base Exchange (BEX) . . . . . . . . . . . . . . . 6 1.2. The HIP Base Exchange (BEX) . . . . . . . . . . . . . . . 7
1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 7 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12
skipping to change at page 4, line 42 skipping to change at page 4, line 42
Packet . . . . . . . . . . . . . . . . . . . . . . . 101 Packet . . . . . . . . . . . . . . . . . . . . . . . 101
6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 101 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 101
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 102 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 102
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 102 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 102
6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 102 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 102
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 103 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 103
8. Security Considerations . . . . . . . . . . . . . . . . . . . 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 103
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 110 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 110
11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 111 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 111
11.1. Changes from draft-ietf-hip-rfc5201-bis-15 . . . . . . . 111 11.1. Changes from draft-ietf-hip-rfc5201-bis-16 . . . . . . . 111
11.2. Changes from draft-ietf-hip-rfc5201-bis-14 . . . . . . . 111 11.2. Changes from draft-ietf-hip-rfc5201-bis-15 . . . . . . . 111
11.3. Changes from draft-ietf-hip-rfc5201-bis-13 . . . . . . . 111 11.3. Changes from draft-ietf-hip-rfc5201-bis-14 . . . . . . . 111
11.4. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 111 11.4. Changes from draft-ietf-hip-rfc5201-bis-13 . . . . . . . 112
11.5. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 111 11.5. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 112
11.6. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 112 11.6. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 112
11.7. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 112 11.7. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 112
11.8. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 112 11.8. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 112
11.9. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 112 11.9. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 112
11.10. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 112 11.10. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 112
11.11. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 112 11.11. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 112
11.12. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 113 11.12. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 113
11.13. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 114 11.13. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 113
11.14. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 115 11.14. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 115
11.15. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 115 11.15. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 115
11.16. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 117 11.16. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 116
11.17. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 117 11.17. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 118
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 11.18. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 118
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 118
12.1. Normative References . . . . . . . . . . . . . . . . . . 118 12.1. Normative References . . . . . . . . . . . . . . . . . . 118
12.2. Informative References . . . . . . . . . . . . . . . . . 119 12.2. Informative References . . . . . . . . . . . . . . . . . 120
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 123 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 123
Appendix B. Generating a Public Key Encoding from an HI . . 124 Appendix B. Generating a Public Key Encoding from an HI . . 124
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 124 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 124
C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 125 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 125
C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 125 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 125
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 126 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 126
Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 126 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 126
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 126 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 126
1. Introduction 1. Introduction
skipping to change at page 9, line 47 skipping to change at page 10, line 5
In this section, the properties of the Host Identity and Host In this section, the properties of the Host Identity and Host
Identity Tag are discussed, and the exact format for them is defined. Identity Tag are discussed, and the exact format for them is defined.
In HIP, the public key of an asymmetric key pair is used as the Host In HIP, the public key of an asymmetric key pair is used as the Host
Identity (HI). Correspondingly, the host itself is defined as the Identity (HI). Correspondingly, the host itself is defined as the
entity that holds the private key of the key pair. See the HIP entity that holds the private key of the key pair. See the HIP
architecture specification [I-D.ietf-hip-rfc4423-bis] for more architecture specification [I-D.ietf-hip-rfc4423-bis] for more
details on the difference between an identity and the corresponding details on the difference between an identity and the corresponding
identifier. identifier.
HIP implementations MUST support the Rivest Shamir Adelman (RSA) HIP implementations MUST support the Rivest Shamir Adelman [RSA]
[RFC3110] public key algorithm and the Elliptic Curve Digital public key algorithm and the Elliptic Curve Digital Signature
Signature Algorithm (ECDSA) for generating the HI as defined in Algorithm (ECDSA) for generating the HI as defined in Section 5.2.9.
Section 5.2.9. Additional algorithms MAY be supported. Additional algorithms MAY be supported.
A hashed encoding of the HI, the Host Identity Tag (HIT), is used in A hashed encoding of the HI, the Host Identity Tag (HIT), is used in
protocols to represent the Host Identity. The HIT is 128 bits long protocols to represent the Host Identity. The HIT is 128 bits long
and has the following three key properties: i) it is the same length and has the following three key properties: i) it is the same length
as an IPv6 address and can be used in fixed address-sized fields in as an IPv6 address and can be used in fixed address-sized fields in
APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it
is computationally hard to find a Host Identity key that matches the is computationally hard to find a Host Identity key that matches the
HIT), and iii) the probability of a HIT collision between two hosts HIT), and iii) the probability of a HIT collision between two hosts
is very low, hence, it is infeasible for an attacker to find a is very low, hence, it is infeasible for an attacker to find a
collision with a HIT that is in use. For details on the security collision with a HIT that is in use. For details on the security
skipping to change at page 33, line 10 skipping to change at page 33, line 10
| Receive NOTIFY | Process and stay at ESTABLISHED | | Receive NOTIFY | Process and stay at ESTABLISHED |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 6: ESTABLISHED - HIP association established Table 6: ESTABLISHED - HIP association established
System behavior in state CLOSING, Table 7. System behavior in state CLOSING, Table 7.
+----------------------------+--------------------------------------+ +----------------------------+--------------------------------------+
| Trigger | Action | | Trigger | Action |
+----------------------------+--------------------------------------+ +----------------------------+--------------------------------------+
| User data to send, | Send I1 and stay at CLOSING | | User data to send, | Send I1 and go to I1-SENT |
| requires the creation of | | | requires the creation of | |
| another incarnation of the | | | another incarnation of the | |
| HIP association | | | HIP association | |
| | | | | |
| Receive I1 | Send R1 and stay at CLOSING | | Receive I1 | Send R1 and stay at CLOSING |
| | | | | |
| Receive I2, process | If successful, send R2 and go to | | Receive I2, process | If successful, send R2 and go to |
| | R2-SENT | | | R2-SENT |
| | | | | |
| | If fail, stay at CLOSING | | | If fail, stay at CLOSING |
skipping to change at page 52, line 39 skipping to change at page 52, line 39
Cipher ID identifies the cipher algorithm to be used for Cipher ID identifies the cipher algorithm to be used for
encrypting the contents of the ENCRYPTED parameter encrypting the contents of the ENCRYPTED parameter
The following Cipher IDs are defined: The following Cipher IDs are defined:
Suite ID Value Suite ID Value
RESERVED 0 RESERVED 0
NULL-ENCRYPT 1 ([RFC2410]) NULL-ENCRYPT 1 ([RFC2410])
AES-128-CBC 2 ([RFC3602]) AES-128-CBC 2 ([RFC3602])
DEPRECATED 3 RESERVED 3 (unused value)
AES-256-CBC 4 ([RFC3602]) AES-256-CBC 4 ([RFC3602])
The sender of a HIP_CIPHER parameter MUST make sure that there are no The sender of a HIP_CIPHER parameter MUST make sure that there are no
more than six (6) Cipher IDs in one HIP_CIPHER parameter. more than six (6) Cipher IDs in one HIP_CIPHER parameter.
Conversely, a recipient MUST be prepared to handle received transport Conversely, a recipient MUST be prepared to handle received transport
parameters that contain more than six Cipher IDs by accepting the parameters that contain more than six Cipher IDs by accepting the
first six Cipher IDs and dropping the rest. The limited number of first six Cipher IDs and dropping the rest. The limited number of
Cipher IDs sets the maximum size of the HIP_CIPHER parameter. As the Cipher IDs sets the maximum size of the HIP_CIPHER parameter. As the
default configuration, the HIP_CIPHER parameter MUST contain at least default configuration, the HIP_CIPHER parameter MUST contain at least
one of the mandatory Cipher IDs. There MAY be a configuration option one of the mandatory Cipher IDs. There MAY be a configuration option
that allows the administrator to override this default. that allows the administrator to override this default.
The Responder lists supported and desired Cipher IDs in order of The Responder lists supported and desired Cipher IDs in order of
preference in the R1, up to the maximum of six Cipher IDs. The preference in the R1, up to the maximum of six Cipher IDs. The
Initiator MUST choose only one of the corresponding Cipher IDs. This Initiator MUST choose only one of the corresponding Cipher IDs. This
Cipher ID will be used for generating the ENCRYPTED parameter. Cipher ID will be used for generating the ENCRYPTED parameter.
Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION [RFC2410] is Mandatory implementation: AES-128-CBC. Implementors SHOULD support
included for testing purposes. NULL-ENCRYPT for testing/debugging purposes, but MUST NOT offer or
accept this value unless explicitly configured for testing/debugging
of the HIP protocol.
5.2.9. HOST_ID 5.2.9. HOST_ID
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HI Length |DI-type| DI Length | | HI Length |DI-type| DI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 111, line 24 skipping to change at page 111, line 24
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-15 11.1. Changes from draft-ietf-hip-rfc5201-bis-16
o Clarify that receipt of user data in state CLOSING (Table 7)
results in transition to I1-SENT
o Add academic reference for the first mention of the RSA algorithm
o As part of comment resolution on use of NULL encryption, note that
use of a NULL HIP CIPHER is only to be used when debugging and
testing the HIP protocol. This only pertains to the ENCRYPTED
parameter, which is optional; in practice, if encryption is not
desired, better to just not encrypt the Host ID.
11.2. Changes from draft-ietf-hip-rfc5201-bis-15
o Additional edits to IANA Considerations section based on initial o Additional edits to IANA Considerations section based on initial
IANA review. IANA review.
11.2. Changes from draft-ietf-hip-rfc5201-bis-14 11.3. Changes from draft-ietf-hip-rfc5201-bis-14
o Update source XML to comply with xmlrfcv2 version of the xml2rfc o Update source XML to comply with xmlrfcv2 version of the xml2rfc
tool, resulting in a few table formatting changes. tool, resulting in a few table formatting changes.
o Editorial and minor technical revisions based on IESG review. o Editorial and minor technical revisions based on IESG review.
o Significant revisions to IANA Considerations section based on o Significant revisions to IANA Considerations section based on
initial IANA review. initial IANA review.
11.3. Changes from draft-ietf-hip-rfc5201-bis-13 11.4. Changes from draft-ietf-hip-rfc5201-bis-13
o Update a few references and fix some editorial nits. o Update a few references and fix some editorial nits.
11.4. Changes from draft-ietf-hip-rfc5201-bis-12 11.5. Changes from draft-ietf-hip-rfc5201-bis-12
o Fix I-D nits. o Fix I-D nits.
11.5. Changes from draft-ietf-hip-rfc5201-bis-11 11.6. Changes from draft-ietf-hip-rfc5201-bis-11
o Specify that TRANSPORT_FORMAT_LIST is mandatory in R1 and I2; fix o Specify that TRANSPORT_FORMAT_LIST is mandatory in R1 and I2; fix
incorrect section reference. incorrect section reference.
11.6. Changes from draft-ietf-hip-rfc5201-bis-10 11.7. 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.7. Changes from draft-ietf-hip-rfc5201-bis-09 11.8. 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.8. Changes from draft-ietf-hip-rfc5201-bis-08 11.9. 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.9. Changes from draft-ietf-hip-rfc5201-bis-07 11.10. 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.10. Changes from draft-ietf-hip-rfc5201-bis-06 11.11. 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.11. Changes from draft-ietf-hip-rfc5201-bis-05 11.12. 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 113, line 29 skipping to change at page 113, line 43
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.12. Changes from draft-ietf-hip-rfc5201-bis-04 11.13. 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 114, line 43 skipping to change at page 115, line 9
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.13. Changes from draft-ietf-hip-rfc5201-bis-03 11.14. 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 115, line 30 skipping to change at page 115, line 45
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.14. Changes from draft-ietf-hip-rfc5201-bis-02 11.15. 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.15. Changes from draft-ietf-hip-rfc5201-bis-01 11.16. 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.
skipping to change at page 117, line 40 skipping to change at page 118, line 9
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.16. Changes from draft-ietf-hip-rfc5201-bis-00 11.17. 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.17. Contents of draft-ietf-hip-rfc5201-bis-00 11.18. 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] [FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, Hash Standard", FIPS PUB 180-2, August 2002,
<http://csrc.nist.gov/publications/fips/fips180-2/ <http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2.pdf>. fips180-2.pdf>.
[I-D.ietf-hip-rfc4843-bis] [I-D.ietf-hip-rfc4843-bis]
Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
skipping to change at page 122, line 18 skipping to change at page 122, line 25
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011. Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", RFC 6253, May 2011. Certificates", RFC 6253, May 2011.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, December 2013. of IPv6 Extension Headers", RFC 7045, December 2013.
[RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key
Cryptosystems", Communications of the ACM 21 (2), pp.
120-126, February 1978.
[SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC [SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC
2 , 2000, <http://www.secg.org/>. 2 , 2000, <http://www.secg.org/>.
Appendix A. Using Responder Puzzles Appendix A. Using Responder Puzzles
As mentioned in Section 4.1.1, the Responder may delay state creation As mentioned in Section 4.1.1, the Responder may delay state creation
and still reject most spoofed 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
appendix is to give the implementors an idea on how to implement the appendix is to give the implementors an idea on how to implement the
 End of changes. 31 change blocks. 
49 lines changed or deleted 72 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/