draft-ietf-hip-rfc5201-bis-00.txt   draft-ietf-hip-rfc5201-bis-01.txt 
Network Working Group R. Moskowitz Network Working Group R. Moskowitz
Internet-Draft ICSAlabs Internet-Draft ICSA labs
Obsoletes: 5201 (if approved) P. Jokela, Ed. Obsoletes: 5201 (if approved) P. Jokela, Ed.
Intended status: Standards Track Ericsson Research NomadicLab Intended status: Standards Track Ericsson Research NomadicLab
Expires: February 21, 2011 T. Henderson Expires: March 5, 2011 T. Henderson
The Boeing Company The Boeing Company
August 20, 2010 T. Heer
RWTH Aachen University,
Distributed Systems Group
September 1, 2010
Host Identity Protocol Host Identity Protocol
draft-ietf-hip-rfc5201-bis-00 draft-ietf-hip-rfc5201-bis-01
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 1, line 47 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 5, 2011.
This Internet-Draft will expire on February 21, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 36
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 6 1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 7
1.2. The HIP Base Exchange . . . . . . . . . . . . . . . . . . 7 1.2. The HIP Base Exchange . . . . . . . . . . . . . . . . . . 7
1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 8 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 8
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
3. Host Identifier (HI) and Its Representations . . . . . . . . 9 3. Host Identifier (HI) and Its Representations . . . . . . . . 9
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 10 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 10
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 11 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13
4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 14 4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 14
4.1.3. Authenticated Diffie-Hellman Protocol . . . . . . . . 15 4.1.3. Authenticated Diffie-Hellman Protocol . . . . . . . . 15
4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 16 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 16
4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 17 4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 17
4.1.6. HIP Opportunistic Mode . . . . . . . . . . . . . . . 17 4.1.6. HIP Opportunistic Mode . . . . . . . . . . . . . . . 17
4.2. Updating a HIP Association . . . . . . . . . . . . . . . 19 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 19
4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 19 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 19
4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 20 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 20
4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 21 4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 21
4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 22 4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 22
4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 29 4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 29
4.5. User Data Considerations . . . . . . . . . . . . . . . . 31 4.5. User Data Considerations . . . . . . . . . . . . . . . . 31
4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 31 4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 31
4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 31 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 31
4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 31 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 31
skipping to change at page 4, line 40 skipping to change at page 4, line 42
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 86 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 86
6.12.1. Handling a SEQ Parameter in a Received UPDATE 6.12.1. Handling a SEQ Parameter in a Received UPDATE
Message . . . . . . . . . . . . . . . . . . . . . . . 86 Message . . . . . . . . . . . . . . . . . . . . . . . 86
6.12.2. Handling an ACK Parameter in a Received UPDATE 6.12.2. Handling an ACK Parameter in a Received UPDATE
Packet . . . . . . . . . . . . . . . . . . . . . . . 87 Packet . . . . . . . . . . . . . . . . . . . . . . . 87
6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 88 6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 88
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 88 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 88
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 88 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 88
6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 89 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 89
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 89 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 89
8. Security Considerations . . . . . . . . . . . . . . . . . . . 89 8. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 89
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 89
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94
11.1. Normative References . . . . . . . . . . . . . . . . . . 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 95
11.2. Informative References . . . . . . . . . . . . . . . . . 96 12.1. Normative References . . . . . . . . . . . . . . . . . . 95
12.2. Informative References . . . . . . . . . . . . . . . . . 96
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 98 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 98
Appendix B. Generating a Public Key Encoding from an HI . . . . 99 Appendix B. Generating a Public Key Encoding from an HI . . . . 99
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 100 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 100
C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 101 C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 101
C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 101 C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 101
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 101 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 101
Appendix D. 384-Bit Group . . . . . . . . . . . . . . . . . . . 102 Appendix D. 384-Bit Group . . . . . . . . . . . . . . . . . . . 102
Appendix E. OAKLEY Well-Known Group 1 . . . . . . . . . . . . . 102 Appendix E. OAKLEY Well-Known Group 1 . . . . . . . . . . . . . 102
1. Introduction 1. Introduction
This memo specifies the details of the Host Identity Protocol (HIP). This memo specifies the details of the Host Identity Protocol (HIP).
A high-level description of the protocol and the underlying 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 [rfc4423-bis]. Briefly, the HIP architecture proposes an description [rfc4423-bis]. Briefly, the HIP architecture proposes an
alternative to the dual use of IP addresses as "locators" (routing alternative to the dual use of IP addresses as "locators" (routing
skipping to change at page 6, line 43 skipping to change at page 6, line 43
o "End-Host Mobility and Multihoming with the Host Identity o "End-Host Mobility and Multihoming with the Host Identity
Protocol" [RFC5206]: how to support mobility and multihoming in Protocol" [RFC5206]: how to support mobility and multihoming in
HIP HIP
o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions"
[RFC5205]: how to extend DNS to contain Host Identity information [RFC5205]: how to extend DNS to contain Host Identity information
o "Host Identity Protocol (HIP) Rendezvous Extension" [RFC5204]: o "Host Identity Protocol (HIP) Rendezvous Extension" [RFC5204]:
using a rendezvous mechanism to contact mobile HIP hosts using a rendezvous mechanism to contact mobile HIP hosts
Since the HIP Base Exchange was first developed, there have been a
few advances in cryptography and attacks against cryptographic
systems. As a result, all cryptographic protocols need to be agile.
That is it should be a part of the protocol to switch from one
cryptograhic primitive to another, and reasonable effort should be
doen to support all of the mainstream algorithms. This update to the
Base Exchange adds this needed cryptographic agility while addressing
the downgrade attacks that such flexibility enables. In particular,
Elliptic Curve support (ECDSA and ECDH) and alternative hash
functions have been added.
1.1. A New Namespace and Identifiers 1.1. A New Namespace and Identifiers
The Host Identity Protocol introduces a new namespace, the Host The Host Identity Protocol introduces a new namespace, the Host
Identity namespace. Some ramifications of this new namespace are Identity namespace. Some ramifications of this new namespace are
explained in the HIP architecture description [rfc4423-bis]. explained in the HIP architecture description [rfc4423-bis].
There are two main representations of the Host Identity, the full There are two main representations of the Host Identity, the full
Host Identifier (HI) and the Host Identity Tag (HIT). The HI is a Host Identifier (HI) and the Host Identity Tag (HIT). The HI is a
public key and directly represents the Identity. Since there are public key and directly represents the Identity. Since there are
different public key algorithms that can be used with different key different public key algorithms that can be used with different key
skipping to change at page 8, line 13 skipping to change at page 8, line 21
complex gateway policies. Thus, HIP is not a replacement for IKE. complex gateway policies. Thus, HIP is not a replacement for IKE.
1.3. Memo Structure 1.3. Memo Structure
The rest of this memo is structured as follows. Section 2 defines The rest of this memo is structured as follows. Section 2 defines
the central keywords, notation, and terms used throughout the rest of the central keywords, notation, and terms used throughout the rest of
the document. Section 3 defines the structure of the Host Identity the document. Section 3 defines the structure of the Host Identity
and its various representations. Section 4 gives an overview of the and its various representations. Section 4 gives an overview of the
HIP base exchange protocol. Sections 5 and 6 define the detail HIP base exchange protocol. Sections 5 and 6 define the detail
packet formats and rules for packet processing. Finally, Sections 7, packet formats and rules for packet processing. Finally, Sections 7,
8, and 9 discuss policy, security, and IANA considerations, 9, and 10 discuss policy, security, and IANA considerations,
respectively. respectively.
2. Terms and Definitions 2. Terms and Definitions
2.1. Requirements Terminology 2.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 40, line 17 skipping to change at page 40, line 17
3. If a system implements a new critical parameter, it MUST provide 3. If a system implements a new critical parameter, it MUST provide
the ability to set the associated feature off, such that the the ability to set the associated feature off, such that the
critical parameter is not sent at all. The configuration option critical parameter is not sent at all. The configuration option
must be well documented. Implementations operating in a mode must be well documented. Implementations operating in a mode
adhering to this specification MUST disable the sending of new adhering to this specification MUST disable the sending of new
critical parameters. In other words, the management interface critical parameters. In other words, the management interface
MUST allow vanilla standards-only mode as a default configuration MUST allow vanilla standards-only mode as a default configuration
setting, and MAY allow new critical payloads to be configured on setting, and MAY allow new critical payloads to be configured on
(and off). (and off).
4. See Section 9 for allocation rules regarding Type codes. 4. See Section 10 for allocation rules regarding Type codes.
5.2.3. R1_COUNTER 5.2.3. R1_COUNTER
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, 4 bytes | | Reserved, 4 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 89, line 39 skipping to change at page 89, line 39
preferred transform and local lifetimes. preferred transform and local lifetimes.
The value of K used in the HIP R1 packet can also vary by policy. K The value of K used in the HIP R1 packet can also vary by policy. K
should never be greater than 20, but for trusted partners it could be should never be greater than 20, but for trusted partners it could be
as low as 0. as low as 0.
Responders would need a similar ACL, representing which hosts they Responders would need a similar ACL, representing which hosts they
accept HIP exchanges, and the preferred transform and local accept HIP exchanges, and the preferred transform and local
lifetimes. Wildcarding SHOULD be supported for this ACL also. lifetimes. Wildcarding SHOULD be supported for this ACL also.
8. Security Considerations 8. Changes from RFC 5201
This section summarizes the changes made from [RFC5201].
9. Security Considerations
HIP is designed to provide secure authentication of hosts. HIP also HIP is designed to provide secure authentication of hosts. HIP also
attempts to limit the exposure of the host to various denial-of- attempts to limit the exposure of the host to various denial-of-
service and man-in-the-middle (MitM) attacks. In so doing, HIP service and man-in-the-middle (MitM) attacks. In so doing, HIP
itself is subject to its own DoS and MitM attacks that potentially itself is subject to its own DoS and MitM attacks that potentially
could be more damaging to a host's ability to conduct business as could be more damaging to a host's ability to conduct business as
usual. usual.
The 384-bit Diffie-Hellman Group is targeted to be used in hosts that The 384-bit Diffie-Hellman Group is targeted to be used in hosts that
either do not require or are not powerful enough for handling strong either do not require or are not powerful enough for handling strong
skipping to change at page 92, line 20 skipping to change at page 92, line 25
break up the HIP exchange by sending such an ICMP message to the break up the HIP exchange by sending such an ICMP message to the
Responder before the Initiator has a chance to send a valid I2 Responder before the Initiator has a chance to send a valid I2
message. Hence, the Responder SHOULD NOT act on such an ICMP message. Hence, the Responder SHOULD NOT act on such an ICMP
message. Especially, it SHOULD NOT remove any minimal state created message. Especially, it SHOULD NOT remove any minimal state created
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 10. IANA Considerations
IANA has reserved protocol number 139 for the Host Identity Protocol. IANA has reserved protocol number 139 for the Host Identity Protocol.
This document defines a new 128-bit value under the CGA Message Type This document defines a new 128-bit value under the CGA Message Type
namespace [RFC3972], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, to be namespace [RFC3972], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, to be
used for HIT generation as specified in ORCHID [RFC4843]. used for HIT generation as specified in ORCHID [RFC4843].
This document also creates a set of new namespaces. These are This document also creates a set of new namespaces. These are
described below. described below.
skipping to change at page 94, line 5 skipping to change at page 94, line 11
values 21-30 for informing about problems in authentication or values 21-30 for informing about problems in authentication or
packet integrity verification. Parameter numbers above 30 can be packet integrity verification. Parameter numbers above 30 can be
used for informing about other types of errors or events. Values used for informing about other types of errors or events. Values
51-8191 are error types reserved to be allocated by IANA. Values 51-8191 are error types reserved to be allocated by IANA. Values
8192-16383 are error types for experimentation. Values 16385- 8192-16383 are error types for experimentation. Values 16385-
40959 are status types to be allocated by IANA, and values 40960- 40959 are status types to be allocated by IANA, and values 40960-
65535 are status types for experimentation. New values in ranges 65535 are status types for experimentation. New values in ranges
51-8191 and 16385-40959 are assigned through First Come First 51-8191 and 16385-40959 are assigned through First Come First
Served, with Specification Required. Served, with Specification Required.
10. Acknowledgments 11. Acknowledgments
The drive to create HIP came to being after attending the MALLOC The drive to create HIP came to being after attending the MALLOC
meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman
really gave the original author, Bob Moskowitz, the assist to get HIP really gave the original author, Bob Moskowitz, the assist to get HIP
beyond 5 paragraphs of ideas. It has matured considerably since the beyond 5 paragraphs of ideas. It has matured considerably since the
early versions thanks to extensive input from IETFers. Most early versions thanks to extensive input from IETFers. Most
importantly, its design goals are articulated and are different from importantly, its design goals are articulated and are different from
other efforts in this direction. Particular mention goes to the other efforts in this direction. Particular mention goes to the
members of the NameSpace Research Group of the IRTF. Noel Chiappa members of the NameSpace Research Group of the IRTF. Noel Chiappa
provided valuable input at early stages of discussions about provided valuable input at early stages of discussions about
skipping to change at page 94, line 50 skipping to change at page 95, line 8
Petander, Michael Richardson, Tim Shepard, Jorma Wall, and Jukka Petander, Michael Richardson, Tim Shepard, Jorma Wall, and Jukka
Ylitalo. Our apologies to anyone whose name is missing. Ylitalo. Our apologies to anyone whose name is missing.
Once the HIP Working Group was founded in early 2004, a number of Once the HIP Working Group was founded in early 2004, a number of
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. References 12. References
11.1. Normative References
12.1. Normative References
[FIPS.95-1.1993] National Institute of Standards and [FIPS.95-1.1993] National Institute of Standards and
Technology, "Codes for the Identification of Technology, "Codes for the Identification of
Federal and Federally Assisted Organizations", Federal and Federally Assisted Organizations",
FIPS PUB 95-1, January 1993. FIPS PUB 95-1, January 1993.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, [RFC0768] Postel, J., "User Datagram Protocol", STD 6,
RFC 768, August 1980. RFC 768, August 1980.
[RFC1035] Mockapetris, P., "Domain names - [RFC1035] Mockapetris, P., "Domain names -
skipping to change at page 96, line 39 skipping to change at page 96, line 45
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An
IPv6 Prefix for Overlay Routable Cryptographic IPv6 Prefix for Overlay Routable Cryptographic
Hash Identifiers (ORCHID)", RFC 4843, Hash Identifiers (ORCHID)", RFC 4843,
April 2007. April 2007.
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander,
"Using the Encapsulating Security Payload "Using the Encapsulating Security Payload
(ESP) Transport Format with the Host Identity (ESP) Transport Format with the Host Identity
Protocol (HIP)", RFC 5202, April 2008. Protocol (HIP)", RFC 5202, April 2008.
11.2. Informative References 12.2. Informative References
[AUR03] Aura, T., Nagarajan, A., and A. Gurtov, [AUR03] Aura, T., Nagarajan, A., and A. Gurtov,
"Analysis of the HIP Base Exchange Protocol", "Analysis of the HIP Base Exchange Protocol",
in Proceedings of 10th Australasian Conference in Proceedings of 10th Australasian Conference
on Information Security and Privacy, on Information Security and Privacy,
July 2003. July 2003.
[CRO03] Crosby, SA. and DS. Wallach, "Denial of [CRO03] Crosby, SA. and DS. Wallach, "Denial of
Service via Algorithmic Complexity Attacks", Service via Algorithmic Complexity Attacks",
in Proceedings of Usenix Security Symposium in Proceedings of Usenix Security Symposium
skipping to change at page 97, line 43 skipping to change at page 97, line 50
[RFC2412] Orman, H., "The OAKLEY Key Determination [RFC2412] Orman, H., "The OAKLEY Key Determination
Protocol", RFC 2412, November 1998. Protocol", RFC 2412, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in Writing an IANA Considerations Section in
RFCs", BCP 26, RFC 2434, October 1998. RFCs", BCP 26, RFC 2434, October 1998.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005. Protocol", RFC 4306, December 2005.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and
T. Henderson, "Host Identity Protocol",
RFC 5201, April 2008.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity [RFC5204] Laganier, J. and L. Eggert, "Host Identity
Protocol (HIP) Rendezvous Extension", Protocol (HIP) Rendezvous Extension",
RFC 5204, April 2008. RFC 5204, April 2008.
[RFC5205] Nikander, P. and J. Laganier, "Host Identity [RFC5205] Nikander, P. and J. Laganier, "Host Identity
Protocol (HIP) Domain Name System (DNS) Protocol (HIP) Domain Name System (DNS)
Extensions", RFC 5205, April 2008. Extensions", RFC 5205, April 2008.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J.
Arkko, "End-Host Mobility and Multihoming with Arkko, "End-Host Mobility and Multihoming with
the Host Identity Protocol", RFC 5206, the Host Identity Protocol", RFC 5206,
April 2008. April 2008.
[RFC5338] Henderson, T., Nikander, P., and M. Komu, [RFC5338] Henderson, T., Nikander, P., and M. Komu,
"Using the Host Identity Protocol with Legacy "Using the Host Identity Protocol with Legacy
Applications", RFC 5338, September 2008. Applications", RFC 5338, September 2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3
Multihoming Shim Protocol for IPv6", RFC 5533, Multihoming Shim Protocol for IPv6", RFC 5533,
skipping to change at page 102, line 44 skipping to change at page 102, line 44
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
This has been rigorously verified as a prime. This has been rigorously verified as a prime.
The generator is: 22 (decimal) The generator is: 22 (decimal)
Authors' Addresses Authors' Addresses
Robert Moskowitz Robert Moskowitz
ICSAlabs, An Independent Division of Verizon Business Systems ICSA labs, An Independent Division of Verizon Business
1000 Bent Creek Blvd, Suite 200 1000 Bent Creek Blvd, Suite 200
Mechanicsburg, PA Mechanicsburg, PA
USA USA
EMail: robert.moskowitz@icsalabs.com EMail: robert.moskowitz@icsalabs.com
Petri Jokela (editor) Petri Jokela (editor)
Ericsson Research NomadicLab Ericsson Research NomadicLab
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
Phone: +358 9 299 1 Phone: +358 9 299 1
EMail: petri.jokela@nomadiclab.com EMail: petri.jokela@nomadiclab.com
Thomas R. Henderson Thomas R. Henderson
The Boeing Company The Boeing Company
P.O. Box 3707 P.O. Box 3707
Seattle, WA Seattle, WA
USA USA
EMail: thomas.r.henderson@boeing.com EMail: thomas.r.henderson@boeing.com
Tobias Heer
RWTH Aachen University, Distributed Systems Group
Ahornstrasse 55
Aachen 52062
Germany
EMail: heer@cs.rwth-aachen.de
URI: http://ds.cs.rwth-aachen.de/members/heer
 End of changes. 23 change blocks. 
27 lines changed or deleted 47 lines changed or added

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