draft-ietf-hip-rfc5201-bis-15.txt   draft-ietf-hip-rfc5201-bis-16.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: January 24, 2015 P. Jokela Expires: February 12, 2015 P. Jokela
Ericsson Research NomadicLab Ericsson Research NomadicLab
T. Henderson T. Henderson
University of Washington University of Washington
July 23, 2014 August 11, 2014
Host Identity Protocol Version 2 (HIPv2) Host Identity Protocol Version 2 (HIPv2)
draft-ietf-hip-rfc5201-bis-15 draft-ietf-hip-rfc5201-bis-16
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 January 24, 2015. This Internet-Draft will expire on February 12, 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
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-14 . . . . . . . 111 11.1. Changes from draft-ietf-hip-rfc5201-bis-15 . . . . . . . 111
11.2. Changes from draft-ietf-hip-rfc5201-bis-13 . . . . . . . 111 11.2. Changes from draft-ietf-hip-rfc5201-bis-14 . . . . . . . 111
11.3. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 111 11.3. Changes from draft-ietf-hip-rfc5201-bis-13 . . . . . . . 111
11.4. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 111 11.4. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 111
11.5. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 111 11.5. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 111
11.6. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 111 11.6. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 112
11.7. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 111 11.7. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 112
11.8. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 112 11.8. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 112
11.9. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 112 11.9. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 112
11.10. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 112 11.10. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 112
11.11. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 113 11.11. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 112
11.12. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 114 11.12. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 113
11.13. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 115 11.13. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 114
11.14. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 115 11.14. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 115
11.15. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 117 11.15. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 115
11.16. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 117 11.16. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 117
11.17. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 117
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 117
12.1. Normative References . . . . . . . . . . . . . . . . . . 117 12.1. Normative References . . . . . . . . . . . . . . . . . . 118
12.2. Informative References . . . . . . . . . . . . . . . . . 119 12.2. Informative References . . . . . . . . . . . . . . . . . 119
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 122 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 123
Appendix B. Generating a Public Key Encoding from an HI . . 123 Appendix B. Generating a Public Key Encoding from an HI . . 124
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 123 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 124
C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 124 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 125
C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 124 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 125
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 125 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 126
Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 125 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 126
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 125 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 126
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 44, line 21 skipping to change at page 44, line 21
| | | | | |
| 2048 - 4095 | Parameters related to HIP transport formats | | 2048 - 4095 | Parameters related to HIP transport formats |
| | | | | |
| 4096 - 8191 | Signed parameters allocated through specification | | 4096 - 8191 | Signed parameters allocated through specification |
| | documents | | | documents |
| | | | | |
| 8192 - 32767 | Reserved | | 8192 - 32767 | Reserved |
| | | | | |
| 32768 - 49151 | Free for experimentation. Signed parameters. | | 32768 - 49151 | Free for experimentation. Signed parameters. |
| | | | | |
| 41952 - 61439 | Reserved | | 49152 - 61439 | Reserved |
| | | | | |
| 61440 - 64443 | Signatures and (signed) MACs | | 61440 - 62463 | Signatures and (signed) MACs |
| | | | | |
| 62464 - 63487 | Parameters that are neither signed nor MACed | | 62464 - 63487 | Parameters that are neither signed nor MACed |
| | | | | |
| 63488 - 64511 | Rendezvous and relaying | | 63488 - 64511 | Rendezvous and relaying |
| | | | | |
| 64512 - 65023 | Parameters that are neither signed nor MACed | | 64512 - 65023 | Parameters that are neither signed nor MACed |
| | | | | |
| 65024 - 65535 | Reserved | | 65024 - 65535 | Reserved |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
skipping to change at page 106, line 27 skipping to change at page 106, line 27
when it sent the R1 HIP packet (if it did create one), but wait for when it sent the R1 HIP packet (if it did create one), but wait for
either a valid I2 HIP packet or the natural timeout (that is, if R1 either a valid I2 HIP packet or the natural timeout (that is, if R1
packets are tracked at all). Likewise, the Initiator SHOULD ignore packets are tracked at all). Likewise, the Initiator SHOULD ignore
any ICMP message while waiting for an R2 HIP packet, and SHOULD any ICMP message while waiting for an R2 HIP packet, and SHOULD
delete any pending state only after a natural timeout. delete any pending state only after a natural timeout.
9. IANA Considerations 9. IANA Considerations
IANA has reserved protocol number 139 for the Host Identity Protocol IANA has reserved protocol number 139 for the Host Identity Protocol
and included it in the "IPv6 Extension Header Types" registry and included it in the "IPv6 Extension Header Types" registry
[RFC7045]. No new action regarding this value is required by this [RFC7045] and the "Assigned Internet Protocol Numbers" registry. The
specification. reference in both of these registries should be updated from
[RFC5201] to this specification.
The reference to the 128-bit value under the CGA Message Type The reference to the 128-bit value under the CGA Message Type
namespace [RFC3972] of "0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA" namespace [RFC3972] of "0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA"
should be changed from [RFC5201] to this specification. should be changed from [RFC5201] to this specification.
The following changes to the "Host Identity Protocol (HIP) The following changes to the "Host Identity Protocol (HIP)
Parameters" registries are requested. In many cases, the changes Parameters" registries are requested. In many cases, the changes
required involve updating the reference from [RFC5201] to this required involve updating the reference from [RFC5201] to this
specification, but there are some differences as outlined below. specification, but there are some differences as outlined below.
Allocation terminology is defined in [RFC5226]; any existing Allocation terminology is defined in [RFC5226]; any existing
skipping to change at page 106, line 51 skipping to change at page 107, line 4
HIP Version HIP Version
This document adds the value "2" to the existing registry. The This document adds the value "2" to the existing registry. The
value of "1" should be left with a reference to [RFC5201]. value of "1" should be left with a reference to [RFC5201].
Packet Type Packet Type
The 7-bit Packet Type field in a HIP protocol packet describes the The 7-bit Packet Type field in a HIP protocol packet describes the
type of a HIP protocol message. It is defined in Section 5.1. type of a HIP protocol message. It is defined in Section 5.1.
All existing values referring to [RFC5201] should be updated to All existing values referring to [RFC5201] should be updated to
refer to this specification. Other values should be left refer to this specification. Other values should be left
unchanged. unchanged.
HIT Suite ID HIT Suite ID
This specification creates a new registry for "HIT Suite ID". This specification creates a new registry for "HIT Suite ID".
This is different than the existing registry for "Suite ID" which This is different than the existing registry for "Suite ID" which
can be left unmodified for version 1 of the protocol ([RFC5201]). can be left unmodified for version 1 of the protocol ([RFC5201]).
The registry should be closed to new registrations.
The four-bit HIT Suite ID uses the OGA field in the ORCHID to The four-bit HIT Suite ID uses the OGA field in the ORCHID to
express the type of the HIT. This document defines three HIT express the type of the HIT. This document defines three HIT
Suites (see Appendix E). Suites (see Appendix E).
The HIT Suite ID is also carried in the four higher-order bits of The HIT Suite ID is also carried in the four higher-order bits of
the ID field in the HIT_SUITE_LIST parameter. The four lower- the ID field in the HIT_SUITE_LIST parameter. The four lower-
order bits are reserved for future extensions of the HIT Suite ID order bits are reserved for future extensions of the HIT Suite ID
space beyond 16 values. space beyond 16 values.
skipping to change at page 107, line 35 skipping to change at page 107, line 38
Suite IDs must be allocated carefully to avoid namespace Suite IDs must be allocated carefully to avoid namespace
exhaustion. Moreover, deprecated IDs should be reused after an exhaustion. Moreover, deprecated IDs should be reused after an
appropriate time span. If 16 Suite IDs prove insufficient and appropriate time span. If 16 Suite IDs prove insufficient and
more HIT Suite IDs are needed concurrently, more bits can be used more HIT Suite IDs are needed concurrently, more bits can be used
for the HIT Suite ID by using one HIT Suite ID (0) to indicate for the HIT Suite ID by using one HIT Suite ID (0) to indicate
that more bits should be used. The HIT_SUITE_LIST parameter that more bits should be used. The HIT_SUITE_LIST parameter
already supports 8-bit HIT Suite IDs, should longer IDs be needed. already supports 8-bit HIT Suite IDs, should longer IDs be needed.
Possible extensions of the HIT Suite ID space to accommodate eight Possible extensions of the HIT Suite ID space to accommodate eight
bits and new HIT Suite IDs are defined through IETF Review. bits and new HIT Suite IDs are defined through IETF Review.
Requests to register reused values should include a note that the
value is being reused after a deprecation period, to ensure
appropriate IETF review and approval.
Parameter Type Parameter Type
The 16-bit Type field in a HIP parameter describes the type of the The 16-bit Type field in a HIP parameter describes the type of the
parameter. It is defined in Section 5.2.1. The current values parameter. It is defined in Section 5.2.1. The current values
are defined in Sections 5.2.3 through 5.2.23. The existing are defined in Sections 5.2.3 through 5.2.23. The existing
registry for "Parameter Type" should be updated as follows. registry for "Parameter Type" should be updated as follows.
A new value (129) for R1_COUNTER should be introduced, with a A new value (129) for R1_COUNTER should be introduced, with a
reference to this specification, and the existing value (128) for reference to this specification, and the existing value (128) for
R1_COUNTER left in place with a reference to [RFC5201]. This R1_COUNTER left in place with a reference to [RFC5201]. This
documents the change in value that has occurred in version 2 of documents the change in value that has occurred in version 2 of
this protocol. this protocol. For clarity, we recommend that the name for the
value 128 be changed from "R1_COUNTER" to "R1_Counter (v1 only)".
A new value (579) for a new Parameter Type HIP_CIPHER should be A new value (579) for a new Parameter Type HIP_CIPHER should be
added, with reference to this specification. This Parameter Type added, with reference to this specification. This Parameter Type
functionally replaces the HIP_TRANSFORM Parameter Type (value 577) functionally replaces the HIP_TRANSFORM Parameter Type (value 577)
which can be left in the table with existing reference to which can be left in the table with existing reference to
[RFC5201]. [RFC5201].
A new value (715) for a new Parameter Type HIT_SUITE_LIST should A new value (715) for a new Parameter Type HIT_SUITE_LIST should
be added, with reference to this specification. be added, with reference to this specification.
A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST
should be added, with reference to this specification. should be added, with reference to this specification.
The name of the HMAC Parameter Type (value 61505) should be The name of the HMAC Parameter Type (value 61505) should be
changed to HIP_MAC. The name of the HMAC_2 Parameter Type (value changed to HIP_MAC. The name of the HMAC_2 Parameter Type (value
61569) should be changed to HIP_MAC_2. 61569) should be changed to HIP_MAC_2. The reference should be
changed to this specification.
All other Parameter Types that reference [RFC5201] should be All other Parameter Types that reference [RFC5201] should be
updated to refer to this specification, and Parameter Types that updated to refer to this specification, and Parameter Types that
reference other RFCs should be unchanged. reference other RFCs should be unchanged.
Regarding the range assignments, the Type codes 32768 through Regarding the range assignments, the Type codes 32768 through
49151 (not 49141) should be Reserved for Private Use. Where the 49151 (not 49141) should be Reserved for Private Use. Where the
existing ranges state "First Come First Served with Specification existing ranges state "First Come First Served with Specification
Required", this should be changed to "Specification Required". Required", this should be changed to "Specification Required".
The Type codes 32768 through 49151 are reserved for The Type codes 32768 through 49151 are reserved for
experimentation. Types SHOULD be selected in a random fashion experimentation. Implementors SHOULD select types in a random
from this range, thereby reducing the probability of collisions. fashion from this range, thereby reducing the probability of
A method employing genuine randomness (such as flipping a coin) collisions. A method employing genuine randomness (such as
SHOULD be used. flipping a coin) SHOULD be used.
Group ID Group ID
The eight-bit Group ID values appear in the DIFFIE_HELLMAN The eight-bit Group ID values appear in the DIFFIE_HELLMAN
parameter and the DH_GROUP_LIST parameter and are defined in parameter and the DH_GROUP_LIST parameter and are defined in
Section 5.2.7. This registry should be updated based on the new Section 5.2.7. This registry should be updated based on the new
values specified in Section 5.2.7; values noted as being values specified in Section 5.2.7; values noted as being
DEPRECATED can be left in the table with reference to [RFC5201]. DEPRECATED can be left in the table with reference to [RFC5201].
New values are assigned through IETF Review. New values are assigned through IETF Review.
skipping to change at page 111, line 12 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-14 11.1. Changes from draft-ietf-hip-rfc5201-bis-15
o Additional edits to IANA Considerations section based on initial
IANA review.
11.2. 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.2. Changes from draft-ietf-hip-rfc5201-bis-13 11.3. 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.3. Changes from draft-ietf-hip-rfc5201-bis-12 11.4. Changes from draft-ietf-hip-rfc5201-bis-12
o Fix I-D nits. o Fix I-D nits.
11.4. Changes from draft-ietf-hip-rfc5201-bis-11 11.5. 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.5. Changes from draft-ietf-hip-rfc5201-bis-10 11.6. 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.6. Changes from draft-ietf-hip-rfc5201-bis-09 11.7. 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.7. Changes from draft-ietf-hip-rfc5201-bis-08 11.8. 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.8. Changes from draft-ietf-hip-rfc5201-bis-07 11.9. 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.9. Changes from draft-ietf-hip-rfc5201-bis-06 11.10. 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.10. Changes from draft-ietf-hip-rfc5201-bis-05 11.11. 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 12 skipping to change at page 113, 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.11. Changes from draft-ietf-hip-rfc5201-bis-04 11.12. 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 26 skipping to change at page 114, line 43
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.12. Changes from draft-ietf-hip-rfc5201-bis-03 11.13. 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 13 skipping to change at page 115, line 30
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.13. Changes from draft-ietf-hip-rfc5201-bis-02 11.14. 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.14. Changes from draft-ietf-hip-rfc5201-bis-01 11.15. 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 24 skipping to change at page 117, line 40
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.15. Changes from draft-ietf-hip-rfc5201-bis-00 11.16. 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.16. Contents of draft-ietf-hip-rfc5201-bis-00 11.17. 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
 End of changes. 35 change blocks. 
57 lines changed or deleted 71 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/