draft-ietf-hip-base-04.txt   draft-ietf-hip-base-05.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
Expires: April 27, 2006 Corporation Expires: September 3, 2006 Corporation
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
October 24, 2005 March 2, 2006
Host Identity Protocol Host Identity Protocol
draft-ietf-hip-base-04 draft-ietf-hip-base-05
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 April 27, 2006. This Internet-Draft will expire on September 3, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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. Discussion related to this document protocols, suchs as TCP and UDP. Discussion related to this document
is going on at the IETF HIP Working Group mailing list. is going on at the IETF HIP Working Group mailing list.
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 . . . . . . . . . . . . . . . . . . 5 1.2. The HIP Base Exchange . . . . . . . . . . . . . . . . . . 5
1.3. Memo structure . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Memo structure . . . . . . . . . . . . . . . . . . . . . 6
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 7 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 7
2.1. Requirements Terminology . . . . . . . . . . . . . . . . . 7 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 7
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
3. Host Identifier (HI) and its Representations . . . . . . . . . 9 3. Host Identifier (HI) and its Representations . . . . . . . . 9
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 9 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 9
3.2. Generating a HIT from a HI . . . . . . . . . . . . . . . . 10 3.2. Generating a HIT from a HI . . . . . . . . . . . . . . . 10
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Creating a HIP Association . . . . . . . . . . . . . . . . 12 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.2. Updating a HIP Association . . . . . . . . . . . . . . . . 17 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 17
4.3. Error Processing . . . . . . . . . . . . . . . . . . . . . 18 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 18
4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 19 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 19
4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . . 19 4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 20
4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 20 4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 20
4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . . 27 4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 27
4.5. User Data Considerations . . . . . . . . . . . . . . . . . 29 4.5. User Data Considerations . . . . . . . . . . . . . . . . 29
4.5.1. TCP and UDP Pseudo-header Computation for User Data . 29 4.5.1. TCP and UDP Pseudo-header Computation for User Data . 29
4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 29 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 29
4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 29 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 29
4.5.4. Reboot and SA Timeout Restart of HIP . . . . . . . . . 29 4.5.4. Reboot and SA Timeout Restart of HIP . . . . . . . . 29
4.6. Certificate Distribution . . . . . . . . . . . . . . . . . 30 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 30
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 31 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 31
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . . 31 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 31
5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . . 32 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 32
5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . . 32 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 32
5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 33 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 33
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . . 33 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 33
5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . 35 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 35
5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 36 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 36
5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . . 37 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 37
5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . . 39 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 39
5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . . 40 5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 40
5.2.7. HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 41 5.2.7. HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 41
5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 42 5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.9. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2.9. HMAC . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.10. HMAC_2 . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2.10. HMAC_2 . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.11. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 44 5.2.11. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 44
5.2.12. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 45 5.2.12. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 45
5.2.13. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.2.13. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.14. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.2.14. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.15. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 47 5.2.15. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 47
5.2.16. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 48 5.2.16. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.17. ECHO_REQUEST . . . . . . . . . . . . . . . . . . . . . 51 5.2.17. ECHO_REQUEST . . . . . . . . . . . . . . . . . . . . 51
5.2.18. ECHO_RESPONSE . . . . . . . . . . . . . . . . . . . . 52 5.2.18. ECHO_RESPONSE . . . . . . . . . . . . . . . . . . . . 52
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 52 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 52
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 53 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 53
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 54 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 54
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . . 55 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 55
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . . 57 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 57
5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . . 57 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 57
5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . . 58 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 58
5.3.7. CLOSE - the HIP Association Closing Packet . . . . . . 59 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 59
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 59 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 59
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 59 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 59
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 60 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 60
5.4.2. Other Problems with the HIP Header and Packet 5.4.2. Other Problems with the HIP Header and Packet
Structure . . . . . . . . . . . . . . . . . . . . . . 60 Structure . . . . . . . . . . . . . . . . . . . . . . 60
5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 60 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 60
5.4.4. Non-existing HIP Association . . . . . . . . . . . . . 60 5.4.4. Non-existing HIP Association . . . . . . . . . . . . 60
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 62 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 62
6.1. Processing Outgoing Application Data . . . . . . . . . . . 62 6.1. Processing Outgoing Application Data . . . . . . . . . . 62
6.2. Processing Incoming Application Data . . . . . . . . . . . 63 6.2. Processing Incoming Application Data . . . . . . . . . . 63
6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . . 64 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 64
6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 65 6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 65
6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . . 65 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 65
6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 66 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 66
6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 67 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 67
6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . . 68 6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 68
6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . . 69 6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 69
6.6.2. Processing Incoming ICMP Protocol Unreachable 6.6.2. Processing Incoming ICMP Protocol Unreachable
Messages . . . . . . . . . . . . . . . . . . . . . . . 70 Messages . . . . . . . . . . . . . . . . . . . . . . 70
6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . . 70 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 70
6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 71 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 71
6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 71 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 71
6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . . 71 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 71
6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 73 6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 73
6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . . 74 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 74
6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 76 6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 76
6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . . 76 6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 76
6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . . 77 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 77
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . . 77 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 78
6.12.1. Handling a SEQ parameter in a received UPDATE 6.12.1. Handling a SEQ parameter in a received UPDATE
message . . . . . . . . . . . . . . . . . . . . . . . 78 message . . . . . . . . . . . . . . . . . . . . . . . 78
6.12.2. Handling an ACK Parameter in a Received UPDATE 6.12.2. Handling an ACK Parameter in a Received UPDATE
Packet . . . . . . . . . . . . . . . . . . . . . . . . 78 Packet . . . . . . . . . . . . . . . . . . . . . . . 79
6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 79 6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 80
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . . 79 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 80
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . . 79 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 80
6.16. Dropping HIP Associations . . . . . . . . . . . . . . . . 79 6.16. Dropping HIP Associations . . . . . . . . . . . . . . . . 80
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . . 80 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 81
8. Security Considerations . . . . . . . . . . . . . . . . . . . 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 82
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 89 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 90
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
11.1. Normative References . . . . . . . . . . . . . . . . . . . 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 91
11.2. Informative References . . . . . . . . . . . . . . . . . . 91 11.2. Informative References . . . . . . . . . . . . . . . . . 92
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . . 93 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 94
Appendix B. Generating a HIT from a HI . . . . . . . . . . . . . 94 Appendix B. Generating a HIT from a HI . . . . . . . . . . . . . 95
Appendix C. Example Checksums for HIP Packets . . . . . . . . . . 95 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 96
C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 95 C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 96
C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . . 95 C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 96
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 95 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 96
Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . . 97 Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 98
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 99
Intellectual Property and Copyright Statements . . . . . . . . . . 99 Intellectual Property and Copyright Statements . . . . . . . . . 100
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 [26]. Briefly, the HIP architecture proposes an description [26]. 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
labels) and "identifiers" (endpoint, or host, identifiers). In HIP, labels) and "identifiers" (endpoint, or host, identifiers). In HIP,
public cryptographic keys, of a public/private key pair, are used as public cryptographic keys, of a public/private key pair, are used as
skipping to change at page 17, line 50 skipping to change at page 17, line 50
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.
HIP provides a general purpose UPDATE packet, which can carry HIP provides a general purpose UPDATE packet, which can carry
multiple HIP parameters, for updating the HIP state between two multiple HIP parameters, for updating the HIP state between two
peers. The UPDATE mechanism has the following properties: peers. The UPDATE mechanism has the following properties:
UPDATE messages carry a monotonically increasing sequence number UPDATE messages carry a monotonically increasing sequence number
and are explicitly acknowledged by the peer. Lost UPDATEs or and are explicitly acknowledged by the peer. Lost UPDATEs or
acknowledgments may be recovered via retransmission. Multiple acknowledgments may be recovered via retransmission. Multiple
UPDATE messages may be outstanding. UPDATE messages may be outstanding under certain circumstances.
UPDATE is protected by both HMAC and HIP_SIGNATURE parameters, UPDATE is protected by both HMAC and HIP_SIGNATURE parameters,
since processing UPDATE signatures alone is a potential DoS attack since processing UPDATE signatures alone is a potential DoS attack
against intermediate systems. against intermediate systems.
UPDATE packets are explicitly acknowledged by the use of an
acknowledgment parameter that echoes an individual sequence number
received from the peer. A single UPDATE packet may contain both a
sequence number and one or more acknowledgment numbers (i.e.,
piggybacked acknowledgment(s) for the peer's UPDATE).
The UPDATE packet is defined in Section 5.3.5. The UPDATE packet is defined in Section 5.3.5.
4.3. Error Processing 4.3. Error Processing
HIP error processing behavior depends on whether there exists an HIP error processing behavior depends on whether there exists an
active HIP association or not. In general, if an HIP association active HIP association or not. In general, if an HIP association
exists between the sender and receiver of a packet causing an error exists between the sender and receiver of a packet causing an error
condition, the receiver SHOULD respond with a NOTIFY packet. On the condition, the receiver SHOULD respond with a NOTIFY packet. On the
other hand, if there are no existing HIP associations between the other hand, if there are no existing HIP associations between the
sender and receiver, or the receiver cannot reasonably determine the sender and receiver, or the receiver cannot reasonably determine the
skipping to change at page 45, line 51 skipping to change at page 45, line 51
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 385 Type 385
Length 4 Length 4
Update ID 32-bit sequence number Update ID 32-bit sequence number
The Update ID is an unsigned quantity, initialized by a host to zero The Update ID is an unsigned quantity, initialized by a host to zero
upon moving to ESTABLISHED state. The Update ID has scope within a upon moving to ESTABLISHED state. The Update ID has scope within a
single HIP association, and not across multiple associations or single HIP association, and not across multiple associations or
multiple hosts. The Update ID is incremented by one before each new multiple hosts. The Update ID is incremented by one before each new
UPDATE that is sent by the host (i.e., the first UPDATE packet UPDATE that is sent by the host; the first UPDATE packet originated
originated by a host has an Update ID of 1). by a host has an Update ID of 0.
5.2.14. ACK 5.2.14. ACK
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| peer Update ID | | peer Update ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 48, line 4 skipping to change at page 48, line 4
referred as the "outer" padding. Correspondingly, the padding for referred as the "outer" padding. Correspondingly, the padding for
the parameter(s) encapsulated within the ENCRYPTED parameter is the parameter(s) encapsulated within the ENCRYPTED parameter is
referred as the "inner" padding. referred as the "inner" padding.
The inner padding follows exactly the rules of Section 5.2.1. The The inner padding follows exactly the rules of Section 5.2.1. The
outer padding also follows the same rules but with an exception. outer padding also follows the same rules but with an exception.
Namely, some algorithms require that the data to be encrypted must be Namely, some algorithms require that the data to be encrypted must be
a multiple of the cipher algorithm block size. In this case, the a multiple of the cipher algorithm block size. In this case, the
outer padding MUST include extra padding, as specified by the outer padding MUST include extra padding, as specified by the
encryption algorithm. The size of the extra padding is selected so encryption algorithm. The size of the extra padding is selected so
that the the length of the ENCRYPTED is the minimum value that is that the length of the ENCRYPTED is the minimum value that is both
both multiple of eight and the cipher block size. The encryption multiple of eight and the cipher block size. The encryption
algorithm may specify padding bytes other than zero; for example, AES algorithm may specify padding bytes other than zero; for example, AES
[32] uses the PKCS5 padding scheme [14] (see section 6.1.1) where the [32] uses the PKCS5 padding scheme [14] (see section 6.1.1) where the
remaining n bytes to fill the block each have the value n. remaining n bytes to fill the block each have the value n.
Note that the length of the cipher suite output may be smaller or Note that the length of the cipher suite output may be smaller or
larger than the length of the data to be encrypted, since the larger than the length of the data to be encrypted, since the
encryption process may compress the data or add additional padding to encryption process may compress the data or add additional padding to
the data. the data.
5.2.16. NOTIFY 5.2.16. NOTIFY
skipping to change at page 56, line 45 skipping to change at page 56, line 45
The HIP_TRANSFORM contains the single encryption and integrity The HIP_TRANSFORM contains the single encryption and integrity
transform selected by the Initiator, that will be used to protect the transform selected by the Initiator, that will be used to protect the
HI exchange. The chosen transform MUST correspond to one offered by HI exchange. The chosen transform MUST correspond to one offered by
the Responder in the R1. All implementations MUST support the AES the Responder in the R1. All implementations MUST support the AES
transform [18]. transform [18].
The Initiator's HI MAY be encrypted using the HIP_TRANSFORM The Initiator's HI MAY be encrypted using the HIP_TRANSFORM
encryption algorithm. The keying material is derived from the encryption algorithm. The keying material is derived from the
Diffie-Hellman exchanged as defined in Section 6.5. Diffie-Hellman exchanged as defined in Section 6.5.
The ECHO_RESPONSE contains the the unmodified Opaque data copied from The ECHO_RESPONSE contains the unmodified Opaque data copied from the
the corresponding ECHO_REQUEST parameter. The ECHO_RESPONSE can be corresponding ECHO_REQUEST parameter. The ECHO_RESPONSE can be
either covered by the HMAC and SIGNATURE or not covered. In the either covered by the HMAC and SIGNATURE or not covered. In the
former case, the ECHO_RESPONSE gets Type number 961, in the latter it former case, the ECHO_RESPONSE gets Type number 961, in the latter it
is 63425. is 63425.
The HMAC is calculated over whole HIP envelope, excluding any The HMAC is calculated over whole HIP envelope, excluding any
parameters after the HMAC, as described in Section 6.4.1. The parameters after the HMAC, as described in Section 6.4.1. The
Responder MUST validate the HMAC. Responder MUST validate the HMAC.
The signature is calculated over whole HIP envelope, excluding any The signature is calculated over whole HIP envelope, excluding any
parameters after the HIP_SIGNATURE, as described in Section 5.2.11. parameters after the HIP_SIGNATURE, as described in Section 5.2.11.
skipping to change at page 58, line 40 skipping to change at page 58, line 40
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
The NOTIFY packet is OPTIONAL. The NOTIFY packet MAY be used to The NOTIFY packet is OPTIONAL. The NOTIFY packet MAY be used to
provide information to a peer. Typically, NOTIFY is used to indicate provide information to a peer. Typically, NOTIFY is used to indicate
some type of protocol error or negotiation failure. some type of protocol error or negotiation failure. NOTIFY packets
are unacknowledged.
The HIP header values for the NOTIFY packet: The HIP header values for the NOTIFY packet:
Header: Header:
Packet Type = 17 Packet Type = 17
SRC HIT = Sender's HIT SRC HIT = Sender's HIT
DST HIT = Recipient's HIT, or zero if unknown DST HIT = Recipient's HIT, or zero if unknown
IP ( HIP (<NOTIFY>i, [HOST_ID, ] HIP_SIGNATURE) ) IP ( HIP (<NOTIFY>i, [HOST_ID, ] HIP_SIGNATURE) )
skipping to change at page 60, line 49 skipping to change at page 60, line 49
field, as in the IPv6 case. Note, however, that the resulting ICMPv4 field, as in the IPv6 case. Note, however, that the resulting ICMPv4
message exceeds the typical ICMPv4 message size as defined in [2]. message exceeds the typical ICMPv4 message size as defined in [2].
5.4.4. Non-existing HIP Association 5.4.4. Non-existing HIP Association
If a HIP implementation receives a CLOSE, or UPDATE packet, or any If a HIP implementation receives a CLOSE, or UPDATE packet, or any
other packet whose handling requires an existing association, that other packet whose handling requires an existing association, that
has either a Receiver or Sender HIT that does not match with any has either a Receiver or Sender HIT that does not match with any
existing HIP association, the implementation MAY respond, rate existing HIP association, the implementation MAY respond, rate
limited, with an ICMP packet with the type Parameter Problem, the limited, with an ICMP packet with the type Parameter Problem, the
Pointer pointing to the the beginning of the first HIT that does not Pointer pointing to the beginning of the first HIT that does not
match. match.
A host MUST NOT reply with such an ICMP if it receives any of the A host MUST NOT reply with such an ICMP if it receives any of the
following messages: I1, R2, I2, R2, and NOTIFY. When introducing new following messages: I1, R2, I2, R2, and NOTIFY. When introducing new
packet types, a specification SHOULD define the appropriate rules for packet types, a specification SHOULD define the appropriate rules for
sending or not sending this kind of ICMP replies. sending or not sending this kind of ICMP replies.
6. Packet Processing 6. Packet Processing
Each host is assumed to have a single HIP protocol implementation Each host is assumed to have a single HIP protocol implementation
skipping to change at page 73, line 29 skipping to change at page 73, line 29
implementation may either resend I1 within the retry bounds or implementation may either resend I1 within the retry bounds or
abandon the HIP exchange. abandon the HIP exchange.
12. The system selects the HIP transform from the choices presented 12. The system selects the HIP transform from the choices presented
in the R1 packet and uses the selected values subsequently when in the R1 packet and uses the selected values subsequently when
generating and using encryption keys, and when sending the I2. generating and using encryption keys, and when sending the I2.
If the proposed alternatives are not acceptable to the system, If the proposed alternatives are not acceptable to the system,
it may either resend I1 within the retry bounds or abandon the it may either resend I1 within the retry bounds or abandon the
HIP exchange. HIP exchange.
13. The system initialized the remaining variables in the associated 13. The system initializes the remaining variables in the associated
state, including Update ID counters. state, including Update ID counters.
14. The system prepares and sends an I2, as described in 14. The system prepares and sends an I2, as described in
Section 5.3.3. Section 5.3.3.
15. The system SHOULD start a timer whose timeout value should be 15. The system SHOULD start a timer whose timeout value should be
larger than the worst-case anticipated RTT, and MUST increment a larger than the worst-case anticipated RTT, and MUST increment a
timeout counter associated with the I2. The sender SHOULD timeout counter associated with the I2. The sender SHOULD
retransmit the I2 upon a timeout and restart the timer, up to a retransmit the I2 upon a timeout and restart the timer, up to a
maximum of I2_RETRIES_MAX tries. maximum of I2_RETRIES_MAX tries.
skipping to change at page 75, line 48 skipping to change at page 75, line 48
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.
15. The I2 packet may have the A bit set -- in this case, the system 15. The I2 packet may have the A bit set -- in this case, the system
MAY choose to refuse it by dropping the I2 and returning to MAY choose to refuse it by dropping the I2 and returning to
state UNASSOCIATED. If the A bit is set, the Initiator's HIT is state UNASSOCIATED. If the A bit is set, the Initiator's HIT is
anonymous and should not be stored. anonymous and should not be stored.
16. The system initialized the remaining variables in the associated 16. The system initializes the remaining variables in the associated
state, including Update ID counters. state, including Update ID counters.
17. Upon successful processing of an I2 in states UNASSOCIATED, I1- 17. Upon successful processing of an I2 in states UNASSOCIATED, I1-
SENT, I2-SENT, and R2-SENT, an R2 is sent and the state machine SENT, I2-SENT, and R2-SENT, an R2 is sent and the state machine
transitions to state R2-SENT. transitions to state R2-SENT.
18. Upon successful processing of an I2 in state ESTABLISHED, the 18. Upon successful processing of an I2 in state ESTABLISHED, the
old HIP association is dropped and a new one is installed, an R2 old HIP association is dropped and a new one is installed, an R2
is sent, and the state machine transitions to R2-SENT. is sent, and the state machine transitions to R2-SENT.
skipping to change at page 77, line 18 skipping to change at page 77, line 18
6.11. Sending UPDATE Packets 6.11. Sending UPDATE Packets
A host sends an UPDATE packet when it wants to update some A host sends an UPDATE packet when it wants to update some
information related to a HIP association. There are a number of information related to a HIP association. There are a number of
likely situations, e.g. mobility management and rekeying of an likely situations, e.g. mobility management and rekeying of an
existing ESP Security Association. The following paragraphs define existing ESP Security Association. The following paragraphs define
the conceptual rules for sending an UPDATE packet to the peer. the conceptual rules for sending an UPDATE packet to the peer.
Additional steps can be defined in other documents where the UPDATE Additional steps can be defined in other documents where the UPDATE
packet is used. packet is used.
1. The system increments its own Update ID value by one. The system first determines whether there are any outstanding UPDATE
messages that may conflict with the new UPDATE message under
consideration. When multiple UPDATEs are outstanding (not yet
acknowledged), the sender must assume that such UPDATEs may be
processed in an arbitrary order. Therefore, any new UPDATEs that
depend on a previous outstanding UPDATE being successfully received
and acknowledged MUST be postponed until reception of the necessary
ACK(s) occurs. One way to prevent any conflicts is to only allow one
outstanding UPDATE at a time, but allowing multiple UPDATEs may
improve the performance of mobility and multihoming protocols.
1. The first UPDATE packet is sent with Update ID of zero.
Otherwise, the system increments its own Update ID value by one
before continuing the below steps.
2. The system creates an UPDATE packet that contains a SEQ parameter 2. The system creates an UPDATE packet that contains a SEQ parameter
with the current value of Update ID. The UPDATE packet may also with the current value of Update ID. The UPDATE packet may also
include an ACK of the Update ID found in a received UPDATE SEQ include an ACK of the peer's Update ID found in a received UPDATE
parameter, if any. SEQ parameter, if any.
3. The system sends the created UPDATE packet and starts an UPDATE 3. The system sends the created UPDATE packet and starts an UPDATE
timer. The default value for the timer is 2 * RTT estimate. timer. The default value for the timer is 2 * RTT estimate. If
multiple UPDATEs are outstanding, multiple timers are in effect.
4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE
can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be
exponentially backed off for subsequent retransmissions. exponentially backed off for subsequent retransmissions. If no
acknowledgment is received from the peer after UPDATE_RETRY_MAX
times, the HIP association is considered to be broken and the
state machine should move from state ESTABLISHED to state CLOSING
as depicted in Section 4.4.3. The UPDATE timer is cancelled upon
receiving an ACK from the peer that acknowledges receipt of the
UPDATE.
6.12. Receiving UPDATE Packets 6.12. Receiving UPDATE Packets
When a system receives an UPDATE packet, its processing depends on When a system receives an UPDATE packet, its processing depends on
the state of the HIP association and the presence of and values of the state of the HIP association and the presence of and values of
the SEQ and ACK parameters. Typically, an UPDATE message also the SEQ and ACK parameters. Typically, an UPDATE message also
carries optional parameters whose handling is defined in separate carries optional parameters whose handling is defined in separate
documents. documents.
For each association, the peer's next expected in-sequence Update ID
("peer Update ID") is stored. Initially, this value is zero. Update
ID comparisons of "less than" and "greater than" are performed with
respect to a circular sequence number space.
The sender may send multiple outstanding UPDATE messages. These
messages are processed in the order in which they are received at the
receiver (i.e., no resequencing is performed). When processing
UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs
were previously processed, so that duplicates or retransmissions are
ACKed and not reprocessed. A receiver MAY choose to define a receive
window of Update IDs that it is willing to process at any given time,
and discard received UPDATEs falling outside of that window.
1. If there is no corresponding HIP association, the implementation 1. If there is no corresponding HIP association, the implementation
MAY reply with an ICMP Parameter Problem, as specified in MAY reply with an ICMP Parameter Problem, as specified in
Section 5.4.4. Section 5.4.4.
2. If the association is in the ESTABLISHED state and the SEQ 2. If the association is in the ESTABLISHED state and the SEQ (but
parameter is present, the UPDATE is processed and replied as not ACK) parameter is present, the UPDATE is processed and
described in Section 6.12.1. replied as described in Section 6.12.1.
3. Additionally (or alternatively), if the association is in the 3. If the association is in the ESTABLISHED state and the ACK (but
ESTABLISHED state and there is an ACK (of outstanding Update ID) not SEQ) parameter is present, the UPDATE is processed as
in the UPDATE, the UPDATE is processed as described in described in Section 6.12.2.
Section 6.12.2.
4. If the association is in the ESTABLISHED state and there is both
an ACK and SEQ in the UPDATE, the ACK is first processed as
described in Section 6.12.2 and then the rest of the UPDATE is
processed as described in Section 6.12.1.
6.12.1. Handling a SEQ parameter in a received UPDATE message 6.12.1. Handling a SEQ parameter in a received UPDATE message
1. If the Update ID in the received SEQ is smaller than the stored 1. If the Update ID in the received SEQ is not the next in sequence
Update ID for the peer host, the packet MUST BE dropped as a Update ID and is greater than the receiver's window for new
duplicate. UPDATEs, the packet MUST be dropped.
2. If the Update ID in the received SEQ is equal to the stored 2. If the Update ID in the received SEQ corresponds to an UPDATE
Update ID for the host, the packet is treated as a that has recently been processed, the packet is treated as a
retransmission. The HMAC verification (next step) MUST NOT be retransmission. The HMAC verification (next step) MUST NOT be
skipped. (A byte-by-byte comparison of the received and a stored skipped. (A byte-by-byte comparison of the received and a stored
packet would be OK, though.) It is recommended that a host cache packet would be OK, though.) It is recommended that a host cache
the last packet that was acked to avoid the cost of generating a UPDATE packets sent with ACKs to avoid the cost of generating a
new ACK packet to respond to a replayed UPDATE. The system MUST new ACK packet to respond to a replayed UPDATE. The system MUST
acknowledge, again, such (apparent) UPDATE message acknowledge, again, such (apparent) UPDATE message
retransmissions but SHOULD also consider rate-limiting such retransmissions but SHOULD also consider rate-limiting such
retransmission responses to guard against replay attacks. retransmission responses to guard against replay attacks.
3. The system MUST verify the HMAC in the UPDATE packet. If the 3. The system MUST verify the HMAC in the UPDATE packet. If the
verification fails, the packet MUST be dropped. verification fails, the packet MUST be dropped.
4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the
verification fails, the packet SHOULD be dropped and an error verification fails, the packet SHOULD be dropped and an error
message logged. message logged.
5. If a new SEQ parameter is being processed, the system MUST record 5. If a new SEQ parameter is being processed, the parameters in the
the Update ID in the received SEQ parameter, for replay UPDATE are then processed. The system MUST record the Update ID
protection. in the received SEQ parameter, for replay protection.
6. An UPDATE acknowledgement packet with ACK parameter is prepared 6. An UPDATE acknowledgement packet with ACK parameter is prepared
and sent to the peer. and sent to the peer. This ACK parameter may be included in a
separate UPDATE or piggybacked in an UPDATE with SEQ parameter,
as described in Section Section 5.3.5. The ACK parameter MAY
acknowledge more than one of the peer's Update IDs.
6.12.2. Handling an ACK Parameter in a Received UPDATE Packet 6.12.2. Handling an ACK Parameter in a Received UPDATE Packet
1. The UPDATE packet with ACK must match with an earlier sent UPDATE 1. The sequence number reported in the ACK must match with an
packet. If no match is found, the packet MUST be dropped. earlier sent UPDATE packet that has not already been
acknowledged. If no match is found or if the ACK does not
acknowledge a new UPDATE, the packet MUST either be dropped if no
SEQ parameter is present, or the processing steps in
Section 6.12.1 are followed.
2. The system MUST verify the HMAC in the UPDATE packet. If the 2. The system MUST verify the HMAC in the UPDATE packet. If the
verification fails, the packet MUST be dropped. verification fails, the packet MUST be dropped.
3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the
verification fails, the packet SHOULD be dropped and an error verification fails, the packet SHOULD be dropped and an error
message logged. message logged.
4. The corresponding UPDATE timer is stopped (see Section 6.11) so 4. The corresponding UPDATE timer is stopped (see Section 6.11) so
that the now acknowledged UPDATE is no longer retransmitted. that the now acknowledged UPDATE is no longer retransmitted. If
multiple UPDATEs are newly acknowledged, multiple timers are
stopped.
6.13. Processing NOTIFY Packets 6.13. Processing NOTIFY Packets
Processing NOTIFY packets is OPTIONAL. If processed, any errors Processing NOTIFY packets is OPTIONAL. If processed, any errors
noted by the NOTIFY parameter SHOULD be taken into account by the HIP noted by the NOTIFY parameter SHOULD be taken into account by the HIP
state machine (e.g., by terminating a HIP handshake), and the error state machine (e.g., by terminating a HIP handshake), and the error
SHOULD be logged. SHOULD be logged.
6.14. Processing CLOSE Packets 6.14. Processing CLOSE Packets
skipping to change at page 91, line 36 skipping to change at page 92, line 36
(work in progress), April 2004. (work in progress), April 2004.
[22] Nikander, P., "A Non-Routable IPv6 Prefix for Keyed Hash [22] Nikander, P., "A Non-Routable IPv6 Prefix for Keyed Hash
Identifiers (KHI)", draft-laganier-ipv6-khi-00 (work in Identifiers (KHI)", draft-laganier-ipv6-khi-00 (work in
progress), September 2005. progress), September 2005.
[23] Aboba, B., "The Network Access Identifier", [23] Aboba, B., "The Network Access Identifier",
draft-ietf-radext-rfc2486bis-06 (work in progress), July 2005. draft-ietf-radext-rfc2486bis-06 (work in progress), July 2005.
[24] Jokela, P., "Using ESP transport format with HIP", [24] Jokela, P., "Using ESP transport format with HIP",
draft-ietf-hip-esp-00 (work in progress), July 2005. draft-ietf-hip-esp-01 (work in progress), October 2005.
[25] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. [25] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995.
11.2. Informative References 11.2. Informative References
[26] Moskowitz, R. and P. Nikander, "Host Identity Protocol [26] 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.
[27] Nordmark, E., "Level 3 multihoming shim protocol", [27] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim
draft-ietf-shim6-proto-01 (work in progress), October 2005. protocol", draft-ietf-shim6-proto-03 (work in progress),
December 2005.
[28] Henderson, T. and P. Nikander, "Using HIP with Legacy [28] Henderson, T. and P. Nikander, "Using HIP with Legacy
Applications", draft-henderson-hip-applications-01 (work in Applications", draft-henderson-hip-applications-01 (work in
progress), July 2005. progress), July 2005.
[29] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the HIP [29] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the HIP
Base Exchange Protocol", in Proceedings of 10th Australasian Base Exchange Protocol", in Proceedings of 10th Australasian
Conference on Information Security and Privacy, July 2003. Conference on Information Security and Privacy, July 2003.
[30] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to [30] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to
skipping to change at page 95, line 16 skipping to change at page 96, line 16
The HIP checksum for HIP packets is specified in Section 6.1.2. The HIP checksum for HIP packets is specified in Section 6.1.2.
Checksums for TCP and UDP packets running over HIP-enabled security Checksums for TCP and UDP packets running over HIP-enabled security
associations are specified in Section 3.5. The examples below use IP associations are specified in Section 3.5. The examples below use IP
addresses of 192.168.0.1 and 192.168.0.2 (and their respective IPv4- addresses of 192.168.0.1 and 192.168.0.2 (and their respective IPv4-
compatible IPv6 formats), and HITs with the first two bits "01" compatible IPv6 formats), and HITs with the first two bits "01"
followed by 124 zeroes followed by a decimal 1 or 2, respectively. followed by 124 zeroes followed by a decimal 1 or 2, respectively.
C.1. IPv6 HIP Example (I1) C.1. IPv6 HIP Example (I1)
Source Address: ::c0a8:0001 Source Address: ::192.168.0.1
Destination Address: ::c0a8:0002 Destination Address: ::192.168.0.2
Upper-Layer Packet Length: 40 0x28 Upper-Layer Packet Length: 40 0x28
Next Header: 99 0x63 Next Header: 253 0xfd
Payload Protocol: 59 0x3b Payload Protocol: 59 0x3b
Header Length: 4 0x04 Header Length: 4 0x4
Packet Type: 1 0x01 Packet Type: 1 0x1
Version: 1 0x1 Version: 1 0x1
Reserved: 0 0x0 Reserved: 1 0x1
Control: 0 0x0000 Control: 0 0x0
Checksum: 49672 0xc208 Checksum: 8046 0x1f6e
Sender's HIT: 4000::0001 Sender's HIT : 1100::1
Receiver's HIT: 4000::0002 Receiver's HIT: 1100::2
C.2. IPv4 HIP Packet (I1) C.2. IPv4 HIP Packet (I1)
The IPv4 checksum value for the same example I1 packet is the same as The IPv4 checksum value for the same example I1 packet is the same as
the IPv6 checksum (since the checksums due to the IPv4 and IPv6 the IPv6 checksum (since the checksums due to the IPv4 and IPv6
pseudo-header components are the same). pseudo-header components are the same).
C.3. TCP Segment C.3. TCP Segment
Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets
use the IPv6 pseudo-header format [8], with the HITs used in place of use the IPv6 pseudo-header format [11], with the HITs used in place
the IPv6 addresses. of the IPv6 addresses.
Sender's HIT: 4000::0001 Sender's HIT: 1100::0001
Receiver's HIT: 4000::0002 Receiver's HIT: 1100::0002
Upper-Layer Packet Length: 20 0x14 Upper-Layer Packet Length: 20 0x14
Next Header: 6 0x06 Next Header: 6 0x06
Source port: 32769 0x8001 Source port: 65500 0xffdc
Destination port: 22 0x0016 Destination port: 22 0x0016
Sequence number: 1 0x00000001 Sequence number: 1 0x00000001
Acknowledgment number: 0 0x00000000 Acknowledgment number: 0 0x00000000
Header length: 20 0x14 Header length: 20 0x14
Flags: SYN 0x02 Flags: SYN 0x02
Window size: 5840 0x16d0 Window size: 65535 0xffff
Checksum: 54519 0xd4f7 Checksum: 60301 0xeb8d
Urgent pointer: 0 0x0000 Urgent pointer: 0 0x0000
0x0000: 6000 0000 0014 0640 1100 0000 0000 0000
0x0010: 0000 0000 0000 0002 1100 0000 0000 0000
0x0020: 0000 0000 0000 0002 ffdc 0016 0000 0001
0x0030: 0000 0000 5002 ffff 8deb 0000
Appendix D. 384-bit Group Appendix D. 384-bit Group
This 384-bit group is defined only to be used with HIP. NOTE: The This 384-bit group is defined only to be used with HIP. NOTE: The
security level of this group is very low! The encryption may be security level of this group is very low! The encryption may be
broken in a very short time, even real-time. It should be used only broken in a very short time, even real-time. It should be used only
when the host is not powerful enough (e.g. some PDAs) and when when the host is not powerful enough (e.g. some PDAs) and when
security requirements are low (e.g. during normal web surfing). security requirements are low (e.g. during normal web surfing).
This prime is: 2^384 - 2^320 - 1 + 2^64 * { [ 2^254 pi] + 5857 } This prime is: 2^384 - 2^320 - 1 + 2^64 * { [ 2^254 pi] + 5857 }
skipping to change at page 99, line 41 skipping to change at page 100, line 41
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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 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.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 64 change blocks. 
132 lines changed or deleted 192 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/