draft-ietf-hip-base-07.txt   draft-ietf-hip-base-08.txt 
Network Working Group R. Moskowitz Network Working Group R. Moskowitz
Internet-Draft ICSAlabs, a Division of TruSecure Internet-Draft ICSAlabs, a Division of TruSecure
Intended status: Informational Corporation Expires: December 13, 2007 Corporation
Expires: August 5, 2007 P. Nikander P. Nikander
P. Jokela (editor) P. Jokela (editor)
Ericsson Research NomadicLab Ericsson Research NomadicLab
T. Henderson T. Henderson
The Boeing Company The Boeing Company
February 1, 2007 June 11, 2007
Host Identity Protocol Host Identity Protocol
draft-ietf-hip-base-07 draft-ietf-hip-base-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 5, 2007. This Internet-Draft will expire on December 13, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This memo specifies the details of the Host Identity Protocol (HIP). This memo specifies the details of the Host Identity Protocol (HIP).
HIP allows consenting hosts to securely establish and maintain shared HIP allows consenting hosts to securely establish and maintain shared
IP-layer state, allowing separation of the identifier and locator IP-layer state, allowing separation of the identifier and locator
roles of IP addresses, thereby enabling continuity of communications roles of IP addresses, thereby enabling continuity of communications
across IP address changes. HIP is based on a Sigma-compliant Diffie- across IP address changes. HIP is based on a Sigma-compliant Diffie-
Hellman key exchange, using public-key identifiers from a new Host Hellman key exchange, using public-key identifiers from a new Host
Identity name space for mutual peer authentication. The protocol is Identity name space for mutual peer authentication. The protocol is
designed to be resistant to Denial-of-Service (DoS) and Man-in-the- designed to be resistant to Denial-of-Service (DoS) and Man-in-the-
middle (MitM) attacks, and when used together with another suitable middle (MitM) attacks, and when used together with another suitable
security protocol, such as Encapsulated Security Payload (ESP), it security protocol, such as Encapsulated Security Payload (ESP), it
provides integrity protection and optional encryption for upper layer provides integrity protection and optional encryption for upper layer
protocols, suchs as TCP and UDP. protocols, such as TCP and UDP.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. A New Name Space and Identifiers . . . . . . . . . . . . 5 1.1. A New Name Space and Identifiers . . . . . . . . . . . . 5
1.2. The HIP Base Exchange . . . . . . . . . . . . . . . . . . 6 1.2. The HIP Base Exchange . . . . . . . . . . . . . . . . . . 6
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
skipping to change at page 4, line 4 skipping to change at page 4, line 4
5.4.2. Other Problems with the HIP Header and Packet 5.4.2. Other Problems with the HIP Header and Packet
Structure . . . . . . . . . . . . . . . . . . . . . . 65 Structure . . . . . . . . . . . . . . . . . . . . . . 65
5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 65 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 65
5.4.4. Non-existing HIP Association . . . . . . . . . . . . 65 5.4.4. Non-existing HIP Association . . . . . . . . . . . . 65
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 66 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 66
6.1. Processing Outgoing Application Data . . . . . . . . . . 66 6.1. Processing Outgoing Application Data . . . . . . . . . . 66
6.2. Processing Incoming Application Data . . . . . . . . . . 67 6.2. Processing Incoming Application Data . . . . . . . . . . 67
6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 68 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 68
6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 69 6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 69
6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 69 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 69
6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 70 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 71
6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 71 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 73
6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 72 6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 75
6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 73 6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 76
6.6.2. Processing Incoming ICMP Protocol Unreachable 6.6.2. Processing Incoming ICMP Protocol Unreachable
Messages . . . . . . . . . . . . . . . . . . . . . . 74 Messages . . . . . . . . . . . . . . . . . . . . . . 76
6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 74 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 76
6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 75 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 78
6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 75 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 78
6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 76 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 78
6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 78 6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 80
6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 78 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 80
6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 80 6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 83
6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 80 6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 83
6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 81 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 83
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 82 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 84
6.12.1. Handling a SEQ parameter in a received UPDATE 6.12.1. Handling a SEQ parameter in a received UPDATE
message . . . . . . . . . . . . . . . . . . . . . . . 83 message . . . . . . . . . . . . . . . . . . . . . . . 85
6.12.2. Handling an ACK Parameter in a Received UPDATE 6.12.2. Handling an ACK Parameter in a Received UPDATE
Packet . . . . . . . . . . . . . . . . . . . . . . . 83 Packet . . . . . . . . . . . . . . . . . . . . . . . 86
6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 84 6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 86
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 84 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 86
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 84 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 87
6.16. Dropping HIP Associations . . . . . . . . . . . . . . . . 85 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 87
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 86 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 88
8. Security Considerations . . . . . . . . . . . . . . . . . . . 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 89
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 92 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95
11.1. Normative References . . . . . . . . . . . . . . . . . . 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 95
11.2. Informative References . . . . . . . . . . . . . . . . . 94 11.2. Informative References . . . . . . . . . . . . . . . . . 96
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 96 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 98
Appendix B. Generating a Public Key Encoding from a HI . . . . . 98 Appendix B. Generating a Public Key Encoding from a HI . . . . . 100
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 99 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 101
C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 99 C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 101
C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 99 C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 101
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 99 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 101
Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 101 Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 103
Appendix E. OAKLEY Well-known group 1 . . . . . . . . . . . . . 102 Appendix E. OAKLEY Well-known group 1 . . . . . . . . . . . . . 104
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105
Intellectual Property and Copyright Statements . . . . . . . . . 104 Intellectual Property and Copyright Statements . . . . . . . . . 106
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 [I-D.ietf-hip-arch]. Briefly, the HIP architecture description [I-D.ietf-hip-arch]. Briefly, the HIP architecture
proposes an alternative to the dual use of IP addresses as "locators" proposes an alternative to the dual use of IP addresses as "locators"
(routing labels) and "identifiers" (endpoint, or host, identifiers). (routing labels) and "identifiers" (endpoint, or host, identifiers).
In HIP, public cryptographic keys, of a public/private key pair, are In HIP, public cryptographic keys, of a public/private key pair, are
skipping to change at page 10, line 49 skipping to change at page 10, line 49
The Host Identity Tag is a 128 bits long value -- a hashed encoding The Host Identity Tag is a 128 bits long value -- a hashed encoding
of the Host Identifier. There are two advantages of using a hashed of the Host Identifier. There are two advantages of using a hashed
encoding over the actual Host Identity public key in protocols. encoding over the actual Host Identity public key in protocols.
Firstly, its fixed length makes for easier protocol coding and also Firstly, its fixed length makes for easier protocol coding and also
better manages the packet size cost of this technology. Secondly, it better manages the packet size cost of this technology. Secondly, it
presents a consistent format to the protocol whatever underlying presents a consistent format to the protocol whatever underlying
identity technology is used. identity technology is used.
"An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers
(ORCHID)" [I-D.laganier-ipv6-khi] has been specified to store 128-bit (ORCHID)" [RFC4843] has been specified to store 128-bit hash based
hash based identifier called Overlay Routable Cryptographic Hash identifier called Overlay Routable Cryptographic Hash Identifiers
Identifiers (ORCHID) under a prefix, proposed to be allocated from (ORCHID) under a prefix, proposed to be allocated from the IPv6
the IPv6 address block as defined in [I-D.laganier-ipv6-khi]. The address block as defined in [RFC4843]. The Host Identity Tag is a
Host Identity Tag is a type of ORCHID, based on a SHA-1 hash of the type of ORCHID, based on a SHA-1 hash of the host identity (Section 2
host identity (Section 2 of [I-D.laganier-ipv6-khi]). of [RFC4843]).
3.2. Generating a HIT from a HI 3.2. Generating a HIT from a HI
The HIT MUST be generated according to the ORCHID generation method The HIT MUST be generated according to the ORCHID generation method
described in [I-D.laganier-ipv6-khi] using a context ID value of described in [RFC4843] using a context ID value of 0xF0EF F02F BFF4
0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been 3D0F E793 0C3C 6E61 74EA (this tag value has been generated randomly
generated randomly by the editor of this specification), and an input by the editor of this specification), and an input encoding the Host
encoding the Host Identity field (see Section 5.2.8) present in a HIP Identity field (see Section 5.2.8) present in a HIP payload packet.
payload packet. The hash algorithm SHA-1 has to be used when The hash algorithm SHA-1 has to be used when generating HITs with
generating HITs with this context ID. If a new ORCHID hash algorithm this context ID. If a new ORCHID hash algorithm is needed in the
is needed in the future for HIT generation, a new version of HIP has future for HIT generation, a new version of HIP has to be specified
to be specified with a new ORCHID context ID associated with the new with a new ORCHID context ID associated with the new hash algorithm.
hash algorithm.
For Identities that are either RSA or DSA public keys, this input For Identities that are either RSA or DSA public keys, this input
consists of the public key encoding as specified in the corresponding consists of the public key encoding as specified in the corresponding
DNSSEC document, taking the algorithm specific portion of the RDATA DNSSEC document, taking the algorithm specific portion of the RDATA
part of the KEY RR. There is currently only two defined public key part of the KEY RR. There is currently only two defined public key
algorithms: RSA/SHA1 and DSA. Hence, either of the following algorithms: RSA/SHA1 and DSA. Hence, either of the following
applies: applies:
The RSA public key is encoded as defined in RFC3110 [RFC3110] The RSA public key is encoded as defined in RFC3110 [RFC3110]
Section 2, taking the exponent length (e_len), exponent (e) and Section 2, taking the exponent length (e_len), exponent (e) and
skipping to change at page 18, line 9 skipping to change at page 18, line 9
There are multiple security issues involved with opportunistic mode There are multiple security issues involved with opportunistic mode
that must be carefully addressed in the implementation. Such a set that must be carefully addressed in the implementation. Such a set
up is vulnerable to, e.g., man-in-the-middle attacks, because the up is vulnerable to, e.g., man-in-the-middle attacks, because the
initializing node does not have any public key information about the initializing node does not have any public key information about the
peer. peer.
While this document defines the concept of the opportunistic mode, While this document defines the concept of the opportunistic mode,
and outlines the basic signalling mechanism to trigger it; i.e., send and outlines the basic signalling mechanism to trigger it; i.e., send
an I1 with a NULL destination HIT, this document does not specify the an I1 with a NULL destination HIT, this document does not specify the
details of the opportunistic mode. Especially, its security details of the opportunistic mode. Especially, its security
properties are not discussed beyond the warning above. It is properties are not discussed beyond the warning above. However, the
expected that a separate document will describe the opportunistic authors believe that using the opportunistic mode is no less secure
mode in more detail, including its security properties. than communicating, without any cryptographic protection, over the
current Internet. It is expected that a separate document will
describe the opportunistic mode in more detail, including its
security properties.
4.2. Updating a HIP Association 4.2. Updating a HIP Association
A HIP association between two hosts may need to be updated over time. A HIP association between two hosts may need to be updated over time.
Examples include the need to rekey expiring user data security Examples include the need to rekey expiring user data security
associations, add new security associations, or change IP addresses associations, add new security associations, or change IP addresses
associated with hosts. The UPDATE packet is used for those and other associated with hosts. The UPDATE packet is used for those and other
similar purposes. This document only specifies the UPDATE packet similar purposes. This document only specifies the UPDATE packet
format and basic processing rules, with mandatory parameters. The format and basic processing rules, with mandatory parameters. The
actual usage is defined in separate specifications. actual usage is defined in separate specifications.
skipping to change at page 23, line 18 skipping to change at page 23, line 18
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Receive I1 | Send R1 and stay at I2-SENT | | Receive I1 | Send R1 and stay at I2-SENT |
| | | | | |
| Receive R1, process | If successful, send I2 and cycle at I2-SENT | | Receive R1, process | If successful, send I2 and cycle at I2-SENT |
| | | | | |
| | If fail, stay at I2-SENT | | | If fail, stay at I2-SENT |
| | | | | |
| Receive I2, process | If successful and local HIT is smaller than | | Receive I2, process | If successful and local HIT is smaller than |
| | the peer HIT, drop I2 and stay at I2-SENT | | | the peer HIT, drop I2 and stay at I2-SENT |
| | | | | |
| | If succesful and local HIT is greater than | | | If successful and local HIT is greater than |
| | the peer HIT, send R2 and go to R2-SENT | | | the peer HIT, send R2 and go to R2-SENT |
| | | | | |
| | If fail, stay at I2-SENT | | | If fail, stay at I2-SENT |
| | | | | |
| Receive R2, process | If successful, go to ESTABLISHED | | Receive R2, process | If successful, go to ESTABLISHED |
| | | | | |
| | If fail, stay at I2-SENT | | | If fail, stay at I2-SENT |
| | | | | |
| Receive ANYOTHER | Drop and stay at I2-SENT | | Receive ANYOTHER | Drop and stay at I2-SENT |
| | | | | |
skipping to change at page 33, line 33 skipping to change at page 33, line 33
case that the forthcoming SHIM6 protocol happens to be compatible case that the forthcoming SHIM6 protocol happens to be compatible
with this specification, an implementation that implements both this with this specification, an implementation that implements both this
specification and the SHIM6 protocol may need to check these bits in specification and the SHIM6 protocol may need to check these bits in
order to determine how to handle the packet. order to determine how to handle the packet.
The HIT fields are always 128 bits (16 bytes) long. The HIT fields are always 128 bits (16 bytes) long.
5.1.1. Checksum 5.1.1. Checksum
Since the checksum covers the source and destination addresses in the Since the checksum covers the source and destination addresses in the
IP header, it must be recomputed on HIP-aware NAT devies. IP header, it must be recomputed on HIP-aware NAT devices.
If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460] If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460]
contains the source and destination IPv6 addresses, HIP packet length contains the source and destination IPv6 addresses, HIP packet length
in the pseudo-header length field, a zero field, and the HIP protocol in the pseudo-header length field, a zero field, and the HIP protocol
number (see Section 4) in the Next Header field. The length field is number (see Section 4) in the Next Header field. The length field is
in bytes and can be calculated from the HIP header length field: (HIP in bytes and can be calculated from the HIP header length field: (HIP
Header Length + 1) * 8. Header Length + 1) * 8.
In case of using IPv4, the IPv4 UDP pseudo header format [RFC0768] is In case of using IPv4, the IPv4 UDP pseudo header format [RFC0768] is
used. In the pseudo header, the source and destination addresses are used. In the pseudo header, the source and destination addresses are
skipping to change at page 49, line 24 skipping to change at page 49, line 24
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| peer Update ID | | peer Update ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 449 Type 449
Length variable (multiple of 4) Length variable (multiple of 4)
peer Update ID 32-bit sequence number corresponding to the peer Update ID 32-bit sequence number corresponding to the
Update ID being acked. Update ID being ACKed.
The ACK parameter includes one or more Update IDs that have been The ACK parameter includes one or more Update IDs that have been
received from the peer. The Length field identifies the number of received from the peer. The Length field identifies the number of
peer Update IDs that are present in the parameter. peer Update IDs that are present in the parameter.
5.2.15. ENCRYPTED 5.2.15. ENCRYPTED
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 54, line 29 skipping to change at page 54, line 29
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) | | Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 897 Type 897
Length variable Length variable
Opaque data Opaque data, supposed to be meaningful only to the Opaque data Opaque data, supposed to be meaningful only to the
node that sends ECHO_REQUEST_SIGNED and receives a node that sends ECHO_REQUEST_SIGNED and receives a
corresponding ECHO_RESPONSE_SIGNED or corresponding ECHO_RESPONSE_SIGNED or
ECHO_RESPONSE_UNSINGED. ECHO_RESPONSE_UNSIGNED.
The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data
that the sender wants to get echoed back in the corresponding reply that the sender wants to get echoed back in the corresponding reply
packet. packet.
The ECHO_REQUEST_SIGNED and corresponding echo response parameters The ECHO_REQUEST_SIGNED and corresponding echo response parameters
MAY be used for any purpose where a node wants to carry some state in MAY be used for any purpose where a node wants to carry some state in
a request packet and get it back in a response packet. The a request packet and get it back in a response packet. The
ECHO_REQUEST_SIGNED is covered by the HMAC and SIGNATURE. A HIP ECHO_REQUEST_SIGNED is covered by the HMAC and SIGNATURE. A HIP
packet can contain only one ECHO_REQUEST_SIGNED or packet can contain only one ECHO_REQUEST_SIGNED or
skipping to change at page 55, line 19 skipping to change at page 55, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) | | Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 63661 Type 63661
Length variable Length variable
Opaque data Opaque data, supposed to be meaningful only to the Opaque data Opaque data, supposed to be meaningful only to the
node that sends ECHO_REQUEST_UNSIGNED and receives a node that sends ECHO_REQUEST_UNSIGNED and receives a
corresponding ECHO_RESPONSE_SIGNED or corresponding ECHO_RESPONSE_UNSIGNED.
ECHO_RESPONSE_UNSIGNED.
The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data
that the sender wants to get echoed back in the corresponding reply that the sender wants to get echoed back in the corresponding reply
packet. packet.
The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters
MAY be used for any purpose where a node wants to carry some state in MAY be used for any purpose where a node wants to carry some state in
a request packet and get it back in a response packet. The a request packet and get it back in a response packet. The
ECHO_REQUEST_UNSIGNED is not covered by the HMAC and SIGNATURE. A ECHO_REQUEST_UNSIGNED is not covered by the HMAC and SIGNATURE. A
HIP packet can contain only one ECHO_REQUEST_SIGNED or HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters.
ECHO_REQUEST_UNSIGNED parameter. The ECHO_REQUEST_UNSIGNED parameter It is possible that middle-boxes add ECHO_REQUEST_UNSIGNED parameters
MUST be responded with an ECHO_RESPONSE_UNSIGNED parameter. in HIP packets passing by. The sender has to create the Opaque field
so that it can later identify the corresponding
ECHO_RESPONSE_UNSIGNED parameter.
The ECHO_REQUEST_UNSIGNED parameter MUST be responded with an
ECHO_RESPONSE_UNSIGNED parameter.
5.2.19. ECHO_RESPONSE_SIGNED 5.2.19. ECHO_RESPONSE_SIGNED
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) | | Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 58, line 39 skipping to change at page 58, line 39
SRC HIT = Responder's HIT SRC HIT = Responder's HIT
DST HIT = Initiator's HIT DST HIT = Initiator's HIT
IP ( HIP ( [ R1_COUNTER, ] IP ( HIP ( [ R1_COUNTER, ]
PUZZLE, PUZZLE,
DIFFIE_HELLMAN, DIFFIE_HELLMAN,
HIP_TRANSFORM, HIP_TRANSFORM,
HOST_ID, HOST_ID,
[ ECHO_REQUEST_SIGNED, ] [ ECHO_REQUEST_SIGNED, ]
HIP_SIGNATURE_2 ) HIP_SIGNATURE_2 )
[, ECHO_REQUEST_UNSIGNED ]) <, ECHO_REQUEST_UNSIGNED >i)
Valid control bits: A Valid control bits: A
If the Responder HI is an anonymous one, the A control MUST be set. If the Responder HI is an anonymous one, the A control MUST be set.
The Initiator HIT MUST match the one received in I1. If the The Initiator HIT MUST match the one received in I1. If the
Responder has multiple HIs, the Responder HIT used MUST match Responder has multiple HIs, the Responder HIT used MUST match
Initiator's request. If the Initiator used opportunistic mode, the Initiator's request. If the Initiator used opportunistic mode, the
Responder may select freely among its HIs. See also "HIP Responder may select freely among its HIs. See also "HIP
Opportunistic Mode" (Section 4.1.6)). Opportunistic Mode" (Section 4.1.6)).
skipping to change at page 59, line 42 skipping to change at page 59, line 42
to potentially easier cryptographic attacks and the risk of not to potentially easier cryptographic attacks and the risk of not
having perfect forward security. having perfect forward security.
However, these risks involved in re-using the same key are However, these risks involved in re-using the same key are
statistical; that is, authors are not aware of any mechanism that statistical; that is, authors are not aware of any mechanism that
would allow manipulation of the protocol so that the risk of the re- would allow manipulation of the protocol so that the risk of the re-
use of a any given Responder Diffie-Hellman public key would differ use of a any given Responder Diffie-Hellman public key would differ
from the base probability. Consequently, it is RECOMMENDED that from the base probability. Consequently, it is RECOMMENDED that
implementations avoid re-using the same D-H key with multiple implementations avoid re-using the same D-H key with multiple
Initiators, but because the risk is considered statistical and not Initiators, but because the risk is considered statistical and not
known to be manipulatable, the implementations MAY re-use a key in known to be manipulable, the implementations MAY re-use a key in
order to ease resource constraint implementations and to increase the order to ease resource constraint implementations and to increase the
probability of successful communication with legitimate clients even probability of successful communication with legitimate clients even
under an I1 storm. In particular, when it is too expensive to under an I1 storm. In particular, when it is too expensive to
generate enough of pre-computed R1 packets to supply each potential generate enough of pre-computed R1 packets to supply each potential
Initiator with a different Diffie-Hellman key, the Responder MAY send Initiator with a different Diffie-Hellman key, the Responder MAY send
the same Diffie-Hellman key to several Initiators, thereby creating the same Diffie-Hellman key to several Initiators, thereby creating
the possibility of multiple legitimate Initiators ending up using the the possibility of multiple legitimate Initiators ending up using the
same Responder-side public key. However, as soon as the Responder same Responder-side public key. However, as soon as the Responder
knows that it will use a particular Diffie-Hellman key, it SHOULD knows that it will use a particular Diffie-Hellman key, it SHOULD
stop offering it. This design is aimed to allow resource-constrained stop offering it. This design is aimed to allow resource-constrained
skipping to change at page 61, line 4 skipping to change at page 61, line 4
DST HIT = Responder's HIT DST HIT = Responder's HIT
IP ( HIP ( [R1_COUNTER,] IP ( HIP ( [R1_COUNTER,]
SOLUTION, SOLUTION,
DIFFIE_HELLMAN, DIFFIE_HELLMAN,
HIP_TRANSFORM, HIP_TRANSFORM,
ENCRYPTED { HOST_ID } or HOST_ID, ENCRYPTED { HOST_ID } or HOST_ID,
[ ECHO_RESPONSE_SIGNED ,] [ ECHO_RESPONSE_SIGNED ,]
HMAC, HMAC,
HIP_SIGNATURE HIP_SIGNATURE
[, ECHO_RESPONSE_UNSIGNED] ) ) <, ECHO_RESPONSE_UNSIGNED>i ) )
Valid control bits: A Valid control bits: A
The HITs used MUST match the ones used previously. The HITs used MUST match the ones used previously.
If the Initiator HI is an anonymous one, the A control MUST be set. If the Initiator HI is an anonymous one, the A control MUST be set.
The Initiator MAY include an unmodified copy of the R1_COUNTER The Initiator MAY include an unmodified copy of the R1_COUNTER
parameter received in the corresponding R1 packet into the I2 packet. parameter received in the corresponding R1 packet into the I2 packet.
skipping to change at page 62, line 17 skipping to change at page 62, line 17
SRC HIT = Responder's HIT SRC HIT = Responder's HIT
DST HIT = Initiator's HIT DST HIT = Initiator's HIT
IP ( HIP ( HMAC_2, HIP_SIGNATURE ) ) IP ( HIP ( HMAC_2, HIP_SIGNATURE ) )
Valid control bits: none Valid control bits: none
The HMAC_2 is calculated over whole HIP envelope, with Responder's The HMAC_2 is calculated over whole HIP envelope, with Responder's
HOST_ID parameter concatenated with the HIP envelope. The HOST_ID HOST_ID parameter concatenated with the HIP envelope. The HOST_ID
parameter is removed after the HMAC calculation. The procedure is parameter is removed after the HMAC calculation. The procedure is
described in 8.3.1. described in Section 6.4.1.
The signature is calculated over whole HIP envelope. The signature is calculated over whole HIP envelope.
The Initiator MUST validate both the HMAC and the signature. The Initiator MUST validate both the HMAC and the signature.
5.3.5. UPDATE - the HIP Update Packet 5.3.5. UPDATE - the HIP Update Packet
Support for the UPDATE packet is MANDATORY. Support for the UPDATE packet is MANDATORY.
The HIP header values for the UPDATE packet: The HIP header values for the UPDATE packet:
skipping to change at page 62, line 42 skipping to change at page 62, line 42
DST HIT = Recipient's HIT DST HIT = Recipient's HIT
IP ( HIP ( [SEQ, ACK, ] HMAC, HIP_SIGNATURE ) ) IP ( HIP ( [SEQ, ACK, ] HMAC, HIP_SIGNATURE ) )
Valid control bits: None Valid control bits: None
The UPDATE packet contains mandatory HMAC and HIP_SIGNATURE The UPDATE packet contains mandatory HMAC and HIP_SIGNATURE
parameters, and other optional parameters. parameters, and other optional parameters.
The UPDATE packet contains zero or one SEQ parameter. The presence The UPDATE packet contains zero or one SEQ parameter. The presence
of a SEQ parameter indicates that the receiver MUST ack the UPDATE. of a SEQ parameter indicates that the receiver MUST ACK the UPDATE.
An UPDATE that does not contain a SEQ parameter is simply an ACK of a An UPDATE that does not contain a SEQ parameter is simply an ACK of a
previous UPDATE and itself MUST NOT be acked. previous UPDATE and itself MUST NOT be ACKed.
An UPDATE packet contains zero or one ACK parameters. The ACK An UPDATE packet contains zero or one ACK parameters. The ACK
parameter echoes the SEQ sequence number of the UPDATE packet being parameter echoes the SEQ sequence number of the UPDATE packet being
acked. A host MAY choose to ack more than one UPDATE packet at a ACKed. A host MAY choose to ACK more than one UPDATE packet at a
time; e.g., the ACK may contain the last two SEQ values received, for time; e.g., the ACK may contain the last two SEQ values received, for
robustness to ack loss. ACK values are not cumulative; each received robustness to ACK loss. ACK values are not cumulative; each received
unique SEQ value requires at least one corresponding ACK value in unique SEQ value requires at least one corresponding ACK value in
reply. Received ACKs that are redundant are ignored. reply. Received ACKs that are redundant are ignored.
The UPDATE packet may contain both a SEQ and an ACK parameter. In The UPDATE packet may contain both a SEQ and an ACK parameter. In
this case, the ACK is being piggybacked on an outgoing UPDATE. In this case, the ACK is being piggybacked on an outgoing UPDATE. In
general, UPDATEs carrying SEQ SHOULD be acked upon completion of the general, UPDATEs carrying SEQ SHOULD be ACKed upon completion of the
processing of the UPDATE. A host MAY choose to hold the UPDATE processing of the UPDATE. A host MAY choose to hold the UPDATE
carrying ACK for a short period of time to allow for the possibility carrying ACK for a short period of time to allow for the possibility
of piggybacking the ACK parameter, in a manner similar to TCP delayed of piggybacking the ACK parameter, in a manner similar to TCP delayed
acknowledgments. acknowledgments.
A sender MAY choose to forego reliable transmission of a particular A sender MAY choose to forgo reliable transmission of a particular
UPDATE (e.g., it becomes overcome by events). The semantics are such UPDATE (e.g., it becomes overcome by events). The semantics are such
that the receiver MUST acknowledge the UPDATE but the sender MAY that the receiver MUST acknowledge the UPDATE but the sender MAY
choose to not care about receiving the ACK. choose to not care about receiving the ACK.
UPDATEs MAY be retransmitted without incrementing SEQ. If the same UPDATEs MAY be retransmitted without incrementing SEQ. If the same
subset of parameters is included in multiple UPDATEs with different subset of parameters is included in multiple UPDATEs with different
SEQs, the host MUST ensure that receiver processing of the parameters SEQs, the host MUST ensure that receiver processing of the parameters
multiple times will not result in a protocol error. multiple times will not result in a protocol error.
5.3.6. NOTIFY - the HIP Notify Packet 5.3.6. NOTIFY - the HIP Notify Packet
skipping to change at page 67, line 44 skipping to change at page 67, line 44
1. The incoming datagram is mapped to an existing HIP association, 1. The incoming datagram is mapped to an existing HIP association,
typically using some information from the packet. For example, typically using some information from the packet. For example,
such mapping may be based on ESP Security Parameter Index (SPI). such mapping may be based on ESP Security Parameter Index (SPI).
2. The specific transport format is unwrapped, in a way depending on 2. The specific transport format is unwrapped, in a way depending on
the transport format, yielding a packet that looks like a the transport format, yielding a packet that looks like a
standard (unencrypted) IP packet. If possible, this step SHOULD standard (unencrypted) IP packet. If possible, this step SHOULD
also verify that the packet was indeed (once) sent by the remote also verify that the packet was indeed (once) sent by the remote
HIP host, as identified by the HIP association. HIP host, as identified by the HIP association.
Depending on the used transport mode, the verification method can
vary. While the HI (as well as HIT) is used as the higher layer
identifier, the verification method has to verify that the data
packet was sent by a node identity and that the actual identity
maps to this particular HIT. When using ESP transport format
[I-D.ietf-hip-esp], the verification is done using the SPI value
in the data packet to find the corresponding SA with associated
HIT and key, and decrypting the packet with that associated key.
3. The IP addresses in the datagram are replaced with the HITs 3. The IP addresses in the datagram are replaced with the HITs
associated with the HIP association. Note that this IP-address- associated with the HIP association. Note that this IP-address-
to-HIT conversion step MAY also be performed at some other point to-HIT conversion step MAY also be performed at some other point
in the stack. in the stack.
4. The datagram is delivered to the upper layer. Demultiplexing the 4. The datagram is delivered to the upper layer. Demultiplexing the
datagram the right upper layer socket is based on the HITs. datagram the right upper layer socket is based on the HITs.
6.3. Solving the Puzzle 6.3. Solving the Puzzle
skipping to change at page 69, line 36 skipping to change at page 69, line 46
When processing HMAC_2, the difference is that the HMAC calculation When processing HMAC_2, the difference is that the HMAC calculation
includes a pseudo HOST_ID field containing the Responder's includes a pseudo HOST_ID field containing the Responder's
information as sent in the R1 packet earlier. information as sent in the R1 packet earlier.
Both the Initiator and the Responder should take some care when Both the Initiator and the Responder should take some care when
verifying or calculating the HMAC_2. Specifically, the Responder verifying or calculating the HMAC_2. Specifically, the Responder
should preserve other parameters than the HOST_ID when sending the should preserve other parameters than the HOST_ID when sending the
R2. Also, the Initiator has to preserve the HOST_ID exactly as it R2. Also, the Initiator has to preserve the HOST_ID exactly as it
was received in the R1 packet. was received in the R1 packet.
The scope of the calculation for HMAC and HMAC_2 is:
HMAC: { HIP header | [ Parameters ] }
where Parameters include all HIP parameters of the packet that is
being calculated with Type values from 1 to (HMAC's Type value - 1)
and exclude parameters with Type values greater or equal to HMAC's
Type value.
During HMAC Calculation, the following applies:
o In HIP header, Checksum field is set to zero.
o In HIP header, the Header Length field value is calculated to the
beginning of the HMAC parameter.
Parameter order is described in Section 5.2.1.
HMAC_2: { HIP header | [ Parameters ] | HOST_ID }
where Parameters include all HIP parameters for the packet that is
being calculated with Type values from 1 to (HMAC_2's Type value - 1)
and exclude parameters with Type values greater or equal to HMAC_2's
Type value.
During HMAC calculation, the following applies:
o In HIP header, Checksum field is set to zero.
o In HIP header, the Header Length field value is calculated to the
beginning of the HMAC_2 parameter and added with the length of the
concatenated HOST_ID parameter length.
o HOST_ID parameter is exactly in the form it was received in the R1
packet from the Responder.
Parameter order is described in Section 5.2.1, except that HOST_ID
parameter in this calculation is added to the end.
The HMAC parameter is defined in Section 5.2.9 and HMAC_2 parameter The HMAC parameter is defined in Section 5.2.9 and HMAC_2 parameter
in Section 5.2.10. HMAC calculation and verification process: in Section 5.2.10. HMAC calculation and verification process (the
process applies both to HMAC and HMAC_2 except where HMAC_2 is
mentioned separately) :
Packet sender: Packet sender:
1. Create the HIP packet, without the HMAC or any possible 1. Create the HIP packet, without the HMAC, HIP_SIGNATURE,
HIP_SIGNATURE or HIP_SIGNATURE_2 parameters. HIP_SIGNATURE_2, or any other parameter with greater Type value
than the HMAC parameter has.
2. In case of HMAC_2 calculation, add a HOST_ID (Responder) 2. In case of HMAC_2 calculation, add a HOST_ID (Responder)
parameter to the packet. parameter to the end of the packet.
3. Calculate the Length field in the HIP header. 3. Calculate the Header Length field in the HIP header including the
added HOST_ID parameter in case of HMAC_2.
4. Compute the HMAC. 4. Compute the HMAC using either HIP-gl or HIP-lg integrity key
retrieved from KEYMAT as defined in Section 6.5.
5. In case of HMAC_2, remove the HOST_ID parameter from the packet. 5. In case of HMAC_2, remove the HOST_ID parameter from the packet.
6. Add the HMAC parameter to the packet and any HIP_SIGNATURE or 6. Add the HMAC parameter to the packet and any parameter with
HIP_SIGNATURE_2 parameters that may follow. greater Type value than the HMAC's (HMAC_2's) that may follow,
including possible HIP_SIGNATURE or HIP_SIGNATURE_2 parameters
7. Recalculate the Length field in the HIP header. 7. Recalculate the Length field in the HIP header.
Packet receiver: Packet receiver:
1. Verify the HIP header Length field. 1. Verify the HIP header Length field.
2. Remove the HMAC or HMAC_2 parameter, and if the packet contains 2. Remove the HMAC or HMAC_2 parameter, as well as all other
any HIP_SIGNATURE or HIP_SIGNATURE_2 fields, remove them too, parameters that follow it with greater Type value including
saving the contents if they will be needed later. possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the
contents if they will be needed later.
3. In case of HMAC_2, build and add a HOST_ID parameter (with 3. In case of HMAC_2, build and add a HOST_ID parameter (with
Responder information) to the packet. The HOST_ID parameter Responder information) to the packet. The HOST_ID parameter
should be identical to the one previously received from the should be identical to the one previously received from the
Responder. Responder.
4. Recalculate the HIP packet length in the HIP header and clear the 4. Recalculate the HIP packet length in the HIP header and clear the
Checksum field (set it to all zeros). Checksum field (set it to all zeros). In case of HMAC_2, the
length is calculated with the added HOST_ID parameter.
5. Compute the HMAC and verify it against the received HMAC. 5. Compute the HMAC using either HIP-gl or HIP-lg integrity key as
defined in Section 6.5 and verify it against the received HMAC.
6. In case of HMAC_2, remove the HOST_ID parameter from the packet 6. Set Checksum and Header Length field in HIP header to original
values.
7. In case of HMAC_2, remove the HOST_ID parameter from the packet
before further processing. before further processing.
6.4.2. Signature Calculation 6.4.2. Signature Calculation
The following process applies both to the HIP_SIGNATURE and The following process applies both to the HIP_SIGNATURE and
HIP_SIGNATURE_2 parameters. When processing HIP_SIGNATURE_2, the HIP_SIGNATURE_2 parameters. When processing HIP_SIGNATURE_2, the
only difference is that instead of HIP_SIGNATURE parameter, the only difference is that instead of HIP_SIGNATURE parameter, the
HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE
Opaque and Random #I fields are cleared (set to all zeros) before Opaque and Random #I fields are cleared (set to all zeros) before
computing the signature. The HIP_SIGNATURE parameter is defined in computing the signature. The HIP_SIGNATURE parameter is defined in
Section 5.2.11 and the HIP_SIGNATURE_2 parameter in Section 5.2.12. Section 5.2.11 and the HIP_SIGNATURE_2 parameter in Section 5.2.12.
Signature calculation and verification process: The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2
is:
HIP_SIGNATURE: { HIP header | [ Parameters ] }
where Parameters include all HIP parameters for the packet that is
being calculated with Type values from 1 to (HIP_SIGNATURE's Type
value - 1).
During signature calculation, the following apply:
o In HIP header, Checksum field is set to zero.
o In HIP header, the Header Length field value is calculated to the
beginning of the HIP_SIGNATURE parameter.
Parameter order is described in Section 5.2.1.
HIP_SIGNATURE_2: { HIP header | [ Parameters ] }
where Parameters include all HIP parameters for the packet that is
being calculated with Type values from 1 to (HIP_SIGNATURE_2's Type
value - 1).
During signature calculation, the following apply:
o In HIP header, Initiator's HIT field and Checksum fields are set
to zero.
o In HIP header, the Header Length field value is calculated to the
beginning of the HIP_SIGNATURE_2 parameter.
o PUZZLE parameter's Opaque and Random #I fields are set to zero.
Parameter order is described in Section 5.2.1.
Signature calculation and verification process (the process applies
both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in case where
HIP_SIGNATURE_2 is separately mentioned):
Packet sender: Packet sender:
1. Create the HIP packet without the HIP_SIGNATURE parameter or any 1. Create the HIP packet without the HIP_SIGNATURE parameter or any
parameters that follow the HIP_SIGNATURE parameter. parameters that follow the HIP_SIGNATURE parameter.
2. Calculate the Length field and zero the Checksum field in the HIP 2. Calculate the Length field and zero the Checksum field in the HIP
header. header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in
HIP header as well as PUZZLE parameter's Opaque and Random #I
fields to zero.
3. Compute the signature. 3. Compute the signature using the private key corresponding to the
Host Identifier (public key).
4. Add the HIP_SIGNATURE parameter to the packet. 4. Add the HIP_SIGNATURE parameter to the packet.
5. Add any parameters that follow the HIP_SIGNATURE parameter. 5. Add any parameters that follow the HIP_SIGNATURE parameter.
6. Recalculate the Length field in the HIP header, and calculate the 6. Recalculate the Length field in the HIP header, and calculate the
Checksum field. Checksum field.
Packet receiver: Packet receiver:
1. Verify the HIP header Length field. 1. Verify the HIP header Length field.
2. Save the contents of the HIP_SIGNATURE parameter and any 2. Save the contents of the HIP_SIGNATURE parameter and any
parameters following the HIP_SIGNATURE parameter and remove them parameters following the HIP_SIGNATURE parameter and remove them
from the packet. from the packet.
3. Recalculate the HIP packet Length in the HIP header and clear the 3. Recalculate the HIP packet Length in the HIP header and clear the
Checksum field (set it to all zeros). Checksum field (set it to all zeros). In case of
HIP_SIGNATURE_2, set Initiator's HIT field in HIP header as well
as PUZZLE parameter's Opaque and Random #I fields to zero.
4. Compute the signature and verify it against the received 4. Compute the signature and verify it against the received
signature. signature using the packet sender's Host Identifier (public key).
5. Restore the original packet by adding removed parameters (in step
2) and resetting the values that were set to zero (in step 3).
The verification can use either the HI received from a HIP packet, The verification can use either the HI received from a HIP packet,
the HI from a DNS query, if the FQDN has been received in the HOST_ID the HI from a DNS query, if the FQDN has been received in the HOST_ID
packet, or one received by some other means. packet, or one received by some other means.
6.5. HIP KEYMAT Generation 6.5. HIP KEYMAT Generation
HIP keying material is derived from the Diffie-Hellman session key, HIP keying material is derived from the Diffie-Hellman session key,
Kij, produced during the HIP base exchange (Section 4.1.3). The Kij, produced during the HIP base exchange (Section 4.1.3). The
Initiator has Kij during the creation of the I2 packet, and the Initiator has Kij during the creation of the I2 packet, and the
skipping to change at page 72, line 38 skipping to change at page 75, line 4
HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP
packets packets
HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets
The number of bits drawn for a given algorithm is the "natural" size The number of bits drawn for a given algorithm is the "natural" size
of the keys. For the mandatory algorithms, the following sizes of the keys. For the mandatory algorithms, the following sizes
apply: apply:
AES 128 bits AES 128 bits
SHA-1 160 bits SHA-1 160 bits
NULL 0 bits NULL 0 bits
If other key sizes are used, they must be treated as different If other key sizes are used, they must be treated as different
encryption algorithms and defined separtely. encryption algorithms and defined separately.
6.6. Initiation of a HIP Exchange 6.6. Initiation of a HIP Exchange
An implementation may originate a HIP exchange to another host based An implementation may originate a HIP exchange to another host based
on a local policy decision, usually triggered by an application on a local policy decision, usually triggered by an application
datagram, in much the same way that an IPsec IKE key exchange can datagram, in much the same way that an IPsec IKE key exchange can
dynamically create a Security Association. Alternatively, a system dynamically create a Security Association. Alternatively, a system
may initiate a HIP exchange if it has rebooted or timed out, or may initiate a HIP exchange if it has rebooted or timed out, or
otherwise lost its HIP state, as described in Section 4.5.4. otherwise lost its HIP state, as described in Section 4.5.4.
skipping to change at page 73, line 41 skipping to change at page 76, line 12
4. Upon timeout, the sender SHOULD retransmit the I1 and restart the 4. Upon timeout, the sender SHOULD retransmit the I1 and restart the
timer, up to a maximum of I1_RETRIES_MAX tries. timer, up to a maximum of I1_RETRIES_MAX tries.
6.6.1. Sending Multiple I1s in Parallel 6.6.1. Sending Multiple I1s in Parallel
For the sake of minimizing the session establishment latency, an For the sake of minimizing the session establishment latency, an
implementation MAY send the same I1 to more than one of the implementation MAY send the same I1 to more than one of the
Responder's addresses. However, it MUST NOT send to more than three Responder's addresses. However, it MUST NOT send to more than three
(3) addresses in parallel. Furthermore, upon timeout, the (3) addresses in parallel. Furthermore, upon timeout, the
implementation MUST refrain from sending the same I1 packet to implementation MUST refrain from sending the same I1 packet to
multiple addresses. These limitations are placed order to avoid multiple addresses. I.e. if it retries to initialize the connection
after timeout, it MUST NOT send the I1 packet to more than one
destination address. These limitations are placed in order to avoid
congestion of the network, and potential DoS attacks that might congestion of the network, and potential DoS attacks that might
happen, e.g., because someone claims to have hundreds or thousands of happen, e.g., because someone claims to have hundreds or thousands of
addresses which possibly could generate a huge number of I1 messages addresses which possibly could generate a huge number of I1 messages
from the Initiator. from the Initiator.
As the Responder is not guaranteed to distinguish the duplicate I1's As the Responder is not guaranteed to distinguish the duplicate I1's
it receives at several of its addresses (because it avoids to store it receives at several of its addresses (because it avoids to store
states when it answers back an R1), the Initiator may receive several states when it answers back an R1), the Initiator may receive several
duplicate R1's. duplicate R1's.
skipping to change at page 78, line 51 skipping to change at page 81, line 24
received I2 is similar to the one that triggered moving to R2- received I2 is similar to the one that triggered moving to R2-
SENT. If so, it MAY retransmit a previously sent R2, reset the SENT. If so, it MAY retransmit a previously sent R2, reset the
R2-SENT timer, and stay in R2-SENT. R2-SENT timer, and stay in R2-SENT.
4. If the system is in the I2-SENT state, it makes a comparison 4. If the system is in the I2-SENT state, it makes a comparison
between its local and sender's HITs (similarly as in between its local and sender's HITs (similarly as in
Section 6.5). If the local HIT is smaller than the sender's Section 6.5). If the local HIT is smaller than the sender's
HIT, it should drop the I2 packet, use peer Diffie-Hellman key HIT, it should drop the I2 packet, use peer Diffie-Hellman key
and nonce I from the R1 packet received earlier, and get the and nonce I from the R1 packet received earlier, and get the
local Diffie-Hellman key and nonce J from the I2 packet sent to local Diffie-Hellman key and nonce J from the I2 packet sent to
the peer ealier. Otherwise, the system should process the the peer earlier. Otherwise, the system should process the
received I2 packet and drop any previously derived Diffie- received I2 packet and drop any previously derived Diffie-
Hellman keying material Kij it might have formed upon sending Hellman keying material Kij it might have formed upon sending
the I2 previously. The peer Diffie-Hellman key and nonce J are the I2 previously. The peer Diffie-Hellman key and nonce J are
taken from the just arrived I2 and local Diffie-Hellman key and taken from the just arrived I2 and local Diffie-Hellman key and
nonce I are the ones that it sent earlier in the R1 packet. nonce I are the ones that it sent earlier in the R1 packet.
5. If the system is in the I1-SENT state, and the HITs in the I2 5. If the system is in the I1-SENT state, and the HITs in the I2
match those used in the previously sent I1, the system uses this match those used in the previously sent I1, the system uses this
received I2 as the basis for the HIP assocation it was trying to received I2 as the basis for the HIP association it was trying
form, and stops retransmitting I1 (provided that the I2 passes to form, and stops retransmitting I1 (provided that the I2
the below additional checks). passes the below additional checks).
6. If the system is in any other state than R2-SENT, it SHOULD 6. If the system is in any other state than R2-SENT, it SHOULD
check that the echoed R1 generation counter in I2 is within the check that the echoed R1 generation counter in I2 is within the
acceptable range. Implementations MUST accept puzzles from the acceptable range. Implementations MUST accept puzzles from the
current generation and MAY accept puzzles from earlier current generation and MAY accept puzzles from earlier
generations. If the newly received I2 is outside the accepted generations. If the newly received I2 is outside the accepted
range, the I2 is stale (perhaps replayed) and SHOULD be dropped. range, the I2 is stale (perhaps replayed) and SHOULD be dropped.
7. The system MUST validate the solution to the puzzle by computing 7. The system MUST validate the solution to the puzzle by computing
the hash described in Section 5.3.3 using the same RHASH the hash described in Section 5.3.3 using the same RHASH
skipping to change at page 79, line 41 skipping to change at page 82, line 15
9. The system must derive Diffie-Hellman keying material Kij based 9. The system must derive Diffie-Hellman keying material Kij based
on the public value and Group ID in the DIFFIE_HELLMAN on the public value and Group ID in the DIFFIE_HELLMAN
parameter. This key is used to derive the HIP association keys, parameter. This key is used to derive the HIP association keys,
as described in Section 6.5. If the Diffie-Hellman Group ID is as described in Section 6.5. If the Diffie-Hellman Group ID is
unsupported, the I2 packet is silently dropped. unsupported, the I2 packet is silently dropped.
10. The encrypted HOST_ID decrypted by the Initiator encryption key 10. The encrypted HOST_ID decrypted by the Initiator encryption key
defined in Section 6.5. If the decrypted data is not a HOST_ID defined in Section 6.5. If the decrypted data is not a HOST_ID
parameter, the I2 packet is silently dropped. parameter, the I2 packet is silently dropped.
11. The implementation SHOULD also verify that the Initiator's HIT 11. The implementation MUST also verify that the Initiator's HIT in
in the I2 corresponds to the Host Identity sent in the I2. the I2 corresponds to the Host Identity sent in the I2.
12. The system MUST verify the HMAC according to the procedures in 12. The system MUST verify the HMAC according to the procedures in
Section 5.2.9. Section 5.2.9.
13. The system MUST verify the HIP_SIGNATURE according to 13. The system MUST verify the HIP_SIGNATURE according to
Section 5.2.11 and Section 5.3.3. Section 5.2.11 and Section 5.3.3.
14. If the checks above are valid, then the system proceeds with 14. If the checks above are valid, then the system proceeds with
further I2 processing; otherwise, it discards the I2 and remains further I2 processing; otherwise, it discards the I2 and remains
in the same state. in the same state.
skipping to change at page 85, line 5 skipping to change at page 87, line 25
When a host receives a CLOSE_ACK message it verifies that it is in When a host receives a CLOSE_ACK message it verifies that it is in
CLOSING or CLOSED state and that the CLOSE_ACK was in response to the CLOSING or CLOSED state and that the CLOSE_ACK was in response to the
CLOSE (using the included ECHO_REPLY_SIGNED in response to the sent CLOSE (using the included ECHO_REPLY_SIGNED in response to the sent
ECHO_REQUEST_SIGNED). ECHO_REQUEST_SIGNED).
The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state is The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state is
discarded when the state changes to UNASSOCIATED and, after that, the discarded when the state changes to UNASSOCIATED and, after that, the
host MAY respond with an ICMP Parameter Problem to an incoming CLOSE host MAY respond with an ICMP Parameter Problem to an incoming CLOSE
message (See Section 5.4.4). message (See Section 5.4.4).
6.16. Dropping HIP Associations 6.16. Handling State Loss
A HIP implementation is free to drop a HIP association at any time, In the case of system crash and unanticipated state loss, the system
based on its own policy. If a HIP host decides to drop a HIP SHOULD delete the corresponding HIP state, including the keying
association, it deletes the corresponding HIP state, including the material. That is, the state SHOULD NOT be stored on stable storage.
keying material. The implementation MUST also drop the peer's R1 If the implementation does drop the state (as RECOMMENDED), it MUST
generation counter value, unless a local policy explicitly defines also drop the peer's R1 generation counter value, unless a local
that the value of that particular host is stored. An implementation policy explicitly defines that the value of that particular host is
MUST NOT store R1 generation counters by default, but storing R1 stored. An implementation MUST NOT store R1 generation counters by
generation counter values, if done, MUST be configured by explicit default, but storing R1 generation counter values, if done, MUST be
HITs. configured by explicit HITs.
7. HIP Policies 7. HIP Policies
There are a number of variables that will influence the HIP exchanges There are a number of variables that will influence the HIP exchanges
that each host must support. All HIP implementations MUST support that each host must support. All HIP implementations MUST support
more than one simultaneous HIs, at least one of which SHOULD be more than one simultaneous HIs, at least one of which SHOULD be
reserved for anonymous usage. Although anonymous HIs will be rarely reserved for anonymous usage. Although anonymous HIs will be rarely
used as Responder HIs, they will be common for Initiators. Support used as Responder HIs, they will be common for Initiators. Support
for more than two HIs is RECOMMENDED. for more than two HIs is RECOMMENDED.
skipping to change at page 87, line 14 skipping to change at page 89, line 14
8. Security Considerations 8. 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 targetted to be used in hosts The 384-bit Diffie-Hellman Group is targeted to be used in hosts that
that either do not require or that are not powerful enough for either do not require or that are not powerful enough for handling
handling strong cryptography. Although there is a risk that with strong cryptography. Although there is a risk that with suitable
suitable equipment the encryption can be broken in real time, the equipment the encryption can be broken in real time, the 384-bit
384-bit group can provide some protection for end-hosts that are not group can provide some protection for end-hosts that are not able to
able to handle any stronger cryptography. When the security provided handle any stronger cryptography. When the security provided by the
by the 384-bit group is not enough for applications on a host, the 384-bit group is not enough for applications on a host, the support
support for this group should be turned off in the configuration. for this group should be turned off in the configuration.
Denial-of-service attacks often take advantage of the cost of start Denial-of-service attacks often take advantage of the cost of start
of state for a protocol on the Responder compared to the 'cheapness' of state for a protocol on the Responder compared to the 'cheapness'
on the Initiator. HIP makes no attempt to increase the cost of the on the Initiator. HIP makes no attempt to increase the cost of the
start of state on the Initiator, but makes an effort to reduce the start of state on the Initiator, but makes an effort to reduce the
cost to the Responder. This is done by having the Responder start cost to the Responder. This is done by having the Responder start
the 3-way exchange instead of the Initiator, making the HIP protocol the 3-way exchange instead of the Initiator, making the HIP protocol
4 packets long. In doing this, packet 2 becomes a 'stock' packet 4 packets long. In doing this, packet 2 becomes a 'stock' packet
that the Responder MAY use many times, until some Initiator has that the Responder MAY use many times, until some Initiator has
provided a valid response to such and R1 packet. During an I1 storm provided a valid response to such and R1 packet. During an I1 storm
skipping to change at page 90, line 13 skipping to change at page 92, line 13
for an R2 HIP packet, deleting state only after a natural timeout. for an R2 HIP packet, deleting state only after a natural timeout.
9. IANA Considerations 9. IANA Considerations
IANA has reserved protocol number 253 to be used for experimental IANA has reserved protocol number 253 to be used for experimental
purposes (see [RFC3692]). In HIP, this value is used until a purposes (see [RFC3692]). In HIP, this value is used until a
permanent protocol number has been assigned by IANA. permanent protocol number has been assigned by IANA.
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 used for HIT generation as specified in ORCHID [RFC4843].
[I-D.laganier-ipv6-khi].
This document also creates a set of new name spaces. These are This document also creates a set of new name spaces. These are
described below. described below.
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.
The current values are defined in Section 5.3.1 through The current values are defined in Section 5.3.1 through
Section 5.3.8. Section 5.3.8.
skipping to change at page 92, line 32 skipping to change at page 94, line 32
Kocher taught Bob Moskowitz how to make the puzzle exchange expensive Kocher taught Bob Moskowitz how to make the puzzle exchange expensive
for the Initiator to respond, but easy for the Responder to validate. for the Initiator to respond, but easy for the Responder to validate.
Bill Sommerfeld supplied the Birthday concept, which later evolved Bill Sommerfeld supplied the Birthday concept, which later evolved
into the R1 generation counter, to simplify reboot management. Erik into the R1 generation counter, to simplify reboot management. Erik
Nordmark supplied CLOSE-mechanism for closing connections. Rodney Nordmark supplied CLOSE-mechanism for closing connections. Rodney
Thayer and Hugh Daniels provide extensive feedback. In the early Thayer and Hugh Daniels provide extensive feedback. In the early
times of this document, John Gilmore kept Bob Moskowitz challenged to times of this document, John Gilmore kept Bob Moskowitz challenged to
provide something of value. provide something of value.
During the later stages of this document, when the editing baton was During the later stages of this document, when the editing baton was
transfered to Pekka Nikander, the input from the early implementors transferred to Pekka Nikander, the input from the early implementors
were invaluable. Without having actual implementations, this were invaluable. Without having actual implementations, this
document would not be on the level it is now. document would not be on the level it is now.
In the usual IETF fashion, a large number of people have contributed In the usual IETF fashion, a large number of people have contributed
to the actual text or ideas. The list of these people include Jeff to the actual text or ideas. The list of these people include Jeff
Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew
McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik
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.
skipping to change at page 94, line 12 skipping to change at page 96, line 12
Algorithm and Its Use with IPsec", RFC 3602, Algorithm and Its Use with IPsec", RFC 3602,
September 2003. September 2003.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307, Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005. December 2005.
[I-D.laganier-ipv6-khi] [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
Nikander, P., "An IPv6 Prefix for Overlay Routable for Overlay Routable Cryptographic Hash Identifiers
Cryptographic Hash Identifiers (ORCHID)", (ORCHID)", RFC 4843, April 2007.
draft-laganier-ipv6-khi-05 (work in progress),
September 2006.
[I-D.ietf-radext-rfc2486bis] [I-D.ietf-radext-rfc2486bis]
Aboba, B., "The Network Access Identifier", Aboba, B., "The Network Access Identifier",
draft-ietf-radext-rfc2486bis-06 (work in progress), draft-ietf-radext-rfc2486bis-06 (work in progress),
July 2005. July 2005.
[I-D.ietf-hip-esp] [I-D.ietf-hip-esp]
Jokela, P., "Using ESP transport format with HIP", Jokela, P., "Using ESP transport format with HIP",
draft-ietf-hip-esp-04 (work in progress), October 2006. draft-ietf-hip-esp-05 (work in progress), February 2007.
[FIPS95] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. [FIPS95] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995.
11.2. Informative References 11.2. Informative References
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, September 1981.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
skipping to change at page 95, line 4 skipping to change at page 96, line 51
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004. Considered Useful", BCP 82, RFC 3692, January 2004.
[I-D.ietf-hip-arch] [I-D.ietf-hip-arch]
Moskowitz, R. and P. Nikander, "Host Identity Protocol Moskowitz, R. and P. Nikander, "Host Identity Protocol
Architecture", draft-ietf-hip-arch-03 (work in progress), Architecture", draft-ietf-hip-arch-03 (work in progress),
August 2005. August 2005.
[I-D.ietf-shim6-proto] [I-D.ietf-shim6-proto]
Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming
protocol", draft-ietf-shim6-proto-07 (work in progress), Shim Protocol for IPv6", draft-ietf-shim6-proto-08 (work
December 2006. in progress), April 2007.
[I-D.henderson-hip-applications] [I-D.henderson-hip-applications]
Henderson, T. and P. Nikander, "Using HIP with Legacy Henderson, T. and P. Nikander, "Using HIP with Legacy
Applications", draft-henderson-hip-applications-03 (work Applications", draft-henderson-hip-applications-03 (work
in progress), May 2006. in progress), May 2006.
[I-D.ietf-hip-mm] [I-D.ietf-hip-mm]
Nikander, P., "End-Host Mobility and Multihoming with the Henderson, T., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-04 (work in Host Identity Protocol", draft-ietf-hip-mm-05 (work in
progress), June 2006. progress), March 2007.
[I-D.ietf-hip-dns] [I-D.ietf-hip-dns]
Nikander, P. and J. Laganier, "Host Identity Protocol Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions", (HIP) Domain Name System (DNS) Extensions",
draft-ietf-hip-dns-08 (work in progress), October 2006. draft-ietf-hip-dns-09 (work in progress), April 2007.
[I-D.ietf-hip-rvs] [I-D.ietf-hip-rvs]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rvs-05 (work in Rendezvous Extension", draft-ietf-hip-rvs-05 (work in
progress), June 2006. progress), June 2006.
[AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the
HIP Base Exchange Protocol", in Proceedings of 10th HIP Base Exchange Protocol", in Proceedings of 10th
Australasian Conference on Information Security and Australasian Conference on Information Security and
Privacy, July 2003. Privacy, July 2003.
skipping to change at page 104, line 7 skipping to change at page 106, line 7
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 64 change blocks. 
149 lines changed or deleted 259 lines changed or added

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