draft-ietf-hip-base-08.txt		draft-ietf-hip-base-09.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: December 13, 2007 Corporation		Expires: April 4, 2008 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
	June 11, 2007		October 2, 2007
	Host Identity Protocol		Host Identity Protocol
	draft-ietf-hip-base-08		draft-ietf-hip-base-09
	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 December 13, 2007.		This Internet-Draft will expire on April 4, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (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
	skipping to change at page 2, line 41		skipping to change at page 2, line 41
	3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10		3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10
	3.2. Generating a HIT from a HI . . . . . . . . . . . . . . . 11		3.2. Generating a HIT from a HI . . . . . . . . . . . . . . . 11
	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.1.6. HIP Opportunistic Mode . . . . . . . . . . . . . . . 17		4.1.6. HIP Opportunistic Mode . . . . . . . . . . . . . . . 17
	4.2. Updating a HIP Association . . . . . . . . . . . . . . . 18		4.2. Updating a HIP Association . . . . . . . . . . . . . . . 19
	4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 18		4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 20
	4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 19		4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 20
	4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 20		4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 21
	4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 21		4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 22
	4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 28		4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 29
	4.5. User Data Considerations . . . . . . . . . . . . . . . . 30		4.5. User Data Considerations . . . . . . . . . . . . . . . . 31
	4.5.1. TCP and UDP Pseudo-header Computation for User Data . 30		4.5.1. TCP and UDP Pseudo-header Computation for User Data . 31
	4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 30		4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 31
	4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 30		4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 31
	4.5.4. Reboot and SA Timeout Restart of HIP . . . . . . . . 30		4.5.4. Reboot and SA Timeout Restart of HIP . . . . . . . . 31
	4.6. Certificate Distribution . . . . . . . . . . . . . . . . 31		4.6. Certificate Distribution . . . . . . . . . . . . . . . . 32
	5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 32		5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 33
	5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 32		5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 33
	5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 33		5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 34
	5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 33		5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 34
	5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 34		5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 35
	5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 35		5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 36
	5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 37		5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 38
	5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 39		5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 40
	5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 40		5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 41
	5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 41		5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 42
	5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 42		5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 43
	5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 43		5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 44
	5.2.7. HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 44		5.2.7. HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 45
	5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 45		5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 46
	5.2.9. HMAC . . . . . . . . . . . . . . . . . . . . . . . . 46		5.2.9. HMAC . . . . . . . . . . . . . . . . . . . . . . . . 47
	5.2.10. HMAC_2 . . . . . . . . . . . . . . . . . . . . . . . 47		5.2.10. HMAC_2 . . . . . . . . . . . . . . . . . . . . . . . 48
	5.2.11. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 47		5.2.11. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 48
	5.2.12. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 48		5.2.12. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 49
	5.2.13. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 48		5.2.13. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 49
	5.2.14. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 49		5.2.14. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 50
	5.2.15. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 50		5.2.15. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 51
	5.2.16. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 51		5.2.16. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 52
	5.2.17. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 54		5.2.17. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 55
	5.2.18. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 55		5.2.18. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 56
	5.2.19. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 55		5.2.19. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 56
	5.2.20. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 56		5.2.20. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 57
	5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 56		5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 57
	5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 57		5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 58
	5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 58		5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 59
	5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 60		5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 61
	5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 61		5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 62
	5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 62		5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 63
	5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 63		5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 64
	5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 63		5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 64
	5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 64		5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 65
	5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 64		5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 65
	5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 65		5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 66
	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 . . . . . . . . . . . . . . . . . . . . . . 66
	5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 65		5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 66
	5.4.4. Non-existing HIP Association . . . . . . . . . . . . 65		5.4.4. Non-existing HIP Association . . . . . . . . . . . . 66
	6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 66		6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 67
	6.1. Processing Outgoing Application Data . . . . . . . . . . 66		6.1. Processing Outgoing Application Data . . . . . . . . . . 67
	6.2. Processing Incoming Application Data . . . . . . . . . . 67		6.2. Processing Incoming Application Data . . . . . . . . . . 68
	6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 68		6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 69
	6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 69		6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 70
	6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 69		6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 70
	6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 71		6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 72
	6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 73		6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 74
	6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 75		6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 76
	6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 76		6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 77
	6.6.2. Processing Incoming ICMP Protocol Unreachable		6.6.2. Processing Incoming ICMP Protocol Unreachable
	Messages . . . . . . . . . . . . . . . . . . . . . . 76		Messages . . . . . . . . . . . . . . . . . . . . . . 77
	6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 76		6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 77
	6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 78		6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 79
	6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 78		6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 79
	6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 78		6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 79
	6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 80		6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 81
	6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 80		6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 81
	6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 83		6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 84
	6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 83		6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 84
	6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 83		6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 84
	6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 84		6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 85
	6.12.1. Handling a SEQ parameter in a received UPDATE		6.12.1. Handling a SEQ parameter in a received UPDATE
	message . . . . . . . . . . . . . . . . . . . . . . . 85		message . . . . . . . . . . . . . . . . . . . . . . . 86
	6.12.2. Handling an ACK Parameter in a Received UPDATE		6.12.2. Handling an ACK Parameter in a Received UPDATE
	Packet . . . . . . . . . . . . . . . . . . . . . . . 86		Packet . . . . . . . . . . . . . . . . . . . . . . . 87
	6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 86		6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 87
	6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 86		6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 87
	6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 87		6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 88
	6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 87		6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 88
	7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 88		7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 89
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 89		8. Security Considerations . . . . . . . . . . . . . . . . . . . 90
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 95
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96
	11.1. Normative References . . . . . . . . . . . . . . . . . . 95		11.1. Normative References . . . . . . . . . . . . . . . . . . 96
	11.2. Informative References . . . . . . . . . . . . . . . . . 96		11.2. Informative References . . . . . . . . . . . . . . . . . 97
	Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 98		Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 99
	Appendix B. Generating a Public Key Encoding from a HI . . . . . 100		Appendix B. Generating a Public Key Encoding from a HI . . . . . 101
	Appendix C. Example Checksums for HIP Packets . . . . . . . . . 101		Appendix C. Example Checksums for HIP Packets . . . . . . . . . 102
	C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 101		C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 102
	C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 101		C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 102
	C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 101		C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 102
	Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 103		Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 104
	Appendix E. OAKLEY Well-known group 1 . . . . . . . . . . . . . 104		Appendix E. OAKLEY Well-known group 1 . . . . . . . . . . . . . 105
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106
	Intellectual Property and Copyright Statements . . . . . . . . . 106		Intellectual Property and Copyright Statements . . . . . . . . . 107
	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 6, line 29		skipping to change at page 6, line 29
	packet design helps to make HIP DoS resilient. The protocol		packet design helps to make HIP DoS resilient. The protocol
	exchanges Diffie-Hellman keys in the 2nd and 3rd packets, and		exchanges Diffie-Hellman keys in the 2nd and 3rd packets, and
	authenticates the parties in the 3rd and 4th packets. Additionally,		authenticates the parties in the 3rd and 4th packets. Additionally,
	the Responder starts a puzzle exchange in the 2nd packet, with the		the Responder starts a puzzle exchange in the 2nd packet, with the
	Initiator completing it in the 3rd packet before the Responder stores		Initiator completing it in the 3rd packet before the Responder stores
	any state from the exchange.		any state from the exchange.
	The exchange can use the Diffie-Hellman output to encrypt the Host		The exchange can use the Diffie-Hellman output to encrypt the Host
	Identity of the Initiator in packet 3 (although Aura et al. [AUR03]		Identity of the Initiator in packet 3 (although Aura et al. [AUR03]
	notes that such operation may interfere with packet-inspecting		notes that such operation may interfere with packet-inspecting
	middleboxes), or the Host Identity may instead be sent unencrypted.		middle-boxes), or the Host Identity may instead be sent unencrypted.
	The Responder's Host Identity is not protected. It should be noted,		The Responder's Host Identity is not protected. It should be noted,
	however, that both the Initiator's and the Responder's HITs are		however, that both the Initiator's and the Responder's HITs are
	transported as such (in cleartext) in the packets, allowing an		transported as such (in cleartext) in the packets, allowing an
	eavesdropper with a priori knowledge about the parties to verify		eavesdropper with a priori knowledge about the parties to verify
	their identities.		their identities.
	Data packets start to flow after the 4th packet. The 3rd and 4th HIP		Data packets start to flow after the 4th packet. The 3rd and 4th HIP
	packets may carry a data payload in the future. However, the details		packets may carry a data payload in the future. However, the details
	of this are to be defined later as more implementation experience is		of this are to be defined later as more implementation experience is
	gained.		gained.
	skipping to change at page 17, line 47		skipping to change at page 17, line 47
	not used here as it actually opens up more potential DoS attacks than		not used here as it actually opens up more potential DoS attacks than
	a simple ICMP message.		a simple ICMP message.
	4.1.6. HIP Opportunistic Mode		4.1.6. HIP Opportunistic Mode
	It is possible to initiate a HIP negotiation even if the responder's		It is possible to initiate a HIP negotiation even if the responder's
	HI (and HIT) is unknown. In this case the connection initializing I1		HI (and HIT) is unknown. In this case the connection initializing I1
	packet contains NULL (all zeros) as the destination HIT. This kind		packet contains NULL (all zeros) as the destination HIT. This kind
	of connection setup is called opportunistic mode.		of connection setup is called opportunistic mode.
	There are multiple security issues involved with opportunistic mode		There are both security and API issues involved with the
	that must be carefully addressed in the implementation. Such a set		opportunistic mode.
	up is vulnerable to, e.g., man-in-the-middle attacks, because the
	initializing node does not have any public key information about the
	peer.
	While this document defines the concept of the opportunistic mode,		Given that the responder's HI is not known by the initiator, there
	and outlines the basic signalling mechanism to trigger it; i.e., send		must be suitable API calls that allow the initiator to request,
	an I1 with a NULL destination HIT, this document does not specify the		directly or indirectly, the underlying kernel to initiate the HIP
	details of the opportunistic mode. Especially, its security		base exchange solely based on locators. The responder's HI will be
	properties are not discussed beyond the warning above. However, the		tentatively available in the R1 packet, and in an authenticated form
	authors believe that using the opportunistic mode is no less secure		once the R2 packet has been received and verified. Hence, it could
	than communicating, without any cryptographic protection, over the		be communicated to the application via new API mechanisms. However,
	current Internet. It is expected that a separate document will		with a backwards compatible API the application sees only the
	describe the opportunistic mode in more detail, including its		locators used for the initial contact. Depending on the desired
	security properties.		semantics of the API, this can raise the following issues:
			o The actual locators may later change if an UPDATE message is used,
			even if from the API perspective the session still appears to be
			between specific locators. The locator update is still secure,
			however, and the session is still between the same nodes.
			o Different sessions between the same locators may result in
			connections to different nodes, if the implementation no longer
			remembers which identifier the peer had in another session. This
			is possible when the peer's locator has changed for legitimate
			reasons or when an attacker pretends to be a node that has the
			peer's locator.
			If the HIP implementation and application do not have the same
			understanding of what constitutes a session, this may even happen
			within the same session. For instance, an implementation may not
			know when HIP state can be purged for UDP based applications.
			In addition, the following security considerations apply. The
			generation counter mechanism will be less efficient in protecting
			against replays of the R1 packet, given that the responder can choose
			a replay that uses any HI, not just the one given in the I1 packet.
			More importantly, the opportunistic exchange is vulnerable to man-in-
			the-middle attacks, because the initiator does not have any public
			key information about the peer. To assess the impacts of this
			vulnerability, we compare it to vulnerabilities in current, non-HIP
			capable communications.
			An attacker on the path between the two peers can insert itself as a
			man-in the middle by providing its own identifier to the initiator
			and then initiating another HIP session towards the responder. For
			this to be possible, the initiator must employ opportunistic mode,
			and the responder must be configured to accept a connection from any
			HIP enabled node.
			An attacker outside the path will be unable to do so, given that it
			cannot respond to the messages in the base exchange.
			These properties are characteristic also of communications in the
			current Internet. A client contacting a server without employing
			end-to-end security may find itself talking to the server via a man-
			in-the-middle. Assuming again that the server is willing to talk to
			anyone.
			If end-to-end security is in place, then the worst that can happen in
			both the opportunistic HIP and normal IP cases is denial-of-service;
			an entity on the path can disrupt communications, but will be unable
			to insert itself as a man-in-the-middle.
			However, once the opportunistic exchange has successfully completed,
			HIP provides integrity protection and confidentiality for the
			communications, and can securely change the locators of the
			endpoints.
			As a result, it is believed that the HIP opportunistic mode is at
			least as secure as current IP.
	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 29, line 37		skipping to change at page 30, line 37
	| | +--------------+ | |		| | +--------------+ | |
	| | | | | receive I2, send R2 | |		| | | | | receive I2, send R2 | |
	| | recv+------------+ | +------------------------+ |		| | recv+------------+ | +------------------------+ |
	| | CLOSE,| | | |		| | CLOSE,| | | |
	| | send| No packet sent| | |		| | send| No packet sent| | |
	| | CLOSE_ACK| /received for | timeout | |		| | CLOSE_ACK| /received for | timeout | |
	| | | UAL min, send | +---------+<-+ (UAL+MSL) | |		| | | UAL min, send | +---------+<-+ (UAL+MSL) | |
	| | | CLOSE +--->| CLOSING |--+ retransmit | |		| | | CLOSE +--->| CLOSING |--+ retransmit | |
	| | | +---------+ CLOSE | |		| | | +---------+ CLOSE | |
	+--|------------|----------------------+ | | | | | |		+--|------------|----------------------+ | | | | | |
	| +------------|------------------------+ | | +----------------+ |		+------------|------------------------+ | | +----------------+ |
	| | | +-----------+ +------------------|--+		| | +-----------+ +------------------|--+
	| | +------------+ | receive CLOSE, CLOSE_ACK | |		| +------------+ | receive CLOSE, CLOSE_ACK | |
	| | | | send CLOSE_ACK received or | |		| | | send CLOSE_ACK received or | |
	| | | | timeout | |		| | | timeout | |
	| | | | (UAL+MSL) | |		| | | (UAL+MSL) | |
	| | v v | |		| v v | |
	| | +--------+ receive I2, send R2 | |		| +--------+ receive I2, send R2 | |
	| +------------------------| CLOSED |---------------------------+ |		+------------------------| CLOSED |---------------------------+ |
	+---------------------------+--------+ /----------------------+		+--------+ /----------------------+
	Datagram to send, send I1 ^ | \-------/ timeout (UAL+2MSL),		^ | \-------/ timeout (UAL+2MSL),
	+-+ move to UNASSOCIATED		+-+ move to UNASSOCIATED
	CLOSE received, send CLOSE_ACK		CLOSE received, send CLOSE_ACK
	4.5. User Data Considerations		4.5. User Data Considerations
	4.5.1. TCP and UDP Pseudo-header Computation for User Data		4.5.1. TCP and UDP Pseudo-header Computation for User Data
	When computing TCP and UDP checksums on user data packets that flow		When computing TCP and UDP checksums on user data packets that flow
	through sockets bound to HITs, the IPv6 pseudo-header format		through sockets bound to HITs, the IPv6 pseudo-header format
	[RFC2460] MUST be used, even if the actual addresses on the packet		[RFC2460] MUST be used, even if the actual addresses on the packet
	skipping to change at page 55, line 32		skipping to change at page 56, line 32
	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 one or more ECHO_REQUEST_UNSIGNED parameters.		HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters.
	It is possible that middle-boxes add ECHO_REQUEST_UNSIGNED parameters		It is possible that middle-boxes add ECHO_REQUEST_UNSIGNED parameters
	in HIP packets passing by. The sender has to create the Opaque field		in HIP packets passing by. The sender has to create the Opaque field
	so that it can later identify the corresponding		so that it can later identify and remove the corresponding
	ECHO_RESPONSE_UNSIGNED parameter.		ECHO_RESPONSE_UNSIGNED parameter.
	The ECHO_REQUEST_UNSIGNED parameter MUST be responded with an		The ECHO_REQUEST_UNSIGNED parameter MUST be responded with an
	ECHO_RESPONSE_UNSIGNED parameter.		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 64, line 20		skipping to change at page 65, line 20
	IP ( HIP ( ECHO_REQUEST_SIGNED, HMAC, HIP_SIGNATURE ) )		IP ( HIP ( ECHO_REQUEST_SIGNED, HMAC, HIP_SIGNATURE ) )
	Valid control bits: none		Valid control bits: none
	The sender MUST include an ECHO_REQUEST_SIGNED used to validate		The sender MUST include an ECHO_REQUEST_SIGNED used to validate
	CLOSE_ACK received in response, and both an HMAC and a signature		CLOSE_ACK received in response, and both an HMAC and a signature
	(calculated over the whole HIP envelope).		(calculated over the whole HIP envelope).
	The receiver peer MUST validate both the HMAC and the signature if it		The receiver peer MUST validate both the HMAC and the signature if it
	has a HIP association state, and MUST reply with a CLOSE_ACK		has a HIP association state, and MUST reply with a CLOSE_ACK
	containing an ECHO_REPLY_SIGNED corresponding to the received		containing an ECHO_RESPONSE_SIGNED corresponding to the received
	ECHO_REQUEST_SIGNED.		ECHO_REQUEST_SIGNED.
	5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet		5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet
	The HIP header values for the CLOSE_ACK packet:		The HIP header values for the CLOSE_ACK packet:
	Header:		Header:
	Packet Type = 19		Packet Type = 19
	SRC HIT = Sender's HIT		SRC HIT = Sender's HIT
	DST HIT = Recipient's HIT		DST HIT = Recipient's HIT
	IP ( HIP ( ECHO_REPLY_SIGNED, HMAC, HIP_SIGNATURE ) )		IP ( HIP ( ECHO_RESPONSE_SIGNED, HMAC, HIP_SIGNATURE ) )
	Valid control bits: none		Valid control bits: none
	The sender MUST include both an HMAC and signature (calculated over		The sender MUST include both an HMAC and signature (calculated over
	the whole HIP envelope).		the whole HIP envelope).
	The receiver peer MUST validate both the HMAC and the signature.		The receiver peer MUST validate both the HMAC and the signature.
	5.4. ICMP Messages		5.4. ICMP Messages
	skipping to change at page 70, line 7		skipping to change at page 71, line 7
	The scope of the calculation for HMAC and HMAC_2 is:		The scope of the calculation for HMAC and HMAC_2 is:
	HMAC: { HIP header | [ Parameters ] }		HMAC: { HIP header | [ Parameters ] }
	where Parameters include all HIP parameters of the packet that is		where Parameters include all HIP parameters of the packet that is
	being calculated with Type values from 1 to (HMAC's Type value - 1)		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		and exclude parameters with Type values greater or equal to HMAC's
	Type value.		Type value.
	During HMAC Calculation, the following applies:		During HMAC calculation, the following applies:
	o In HIP header, Checksum field is set to zero.		o In HIP header, Checksum field is set to zero.
	o In HIP header, the Header Length field value is calculated to the		o In HIP header, the Header Length field value is calculated to the
	beginning of the HMAC parameter.		beginning of the HMAC parameter.
	Parameter order is described in Section 5.2.1.		Parameter order is described in Section 5.2.1.
	HMAC_2: { HIP header | [ Parameters ] | HOST_ID }		HMAC_2: { HIP header | [ Parameters ] | HOST_ID }
	where Parameters include all HIP parameters for the packet that is		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)		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		and exclude parameters with Type values greater or equal to HMAC_2's
	Type value.		Type value.
	During HMAC calculation, the following applies:		During HMAC_2 calculation, the following applies:
	o In HIP header, Checksum field is set to zero.		o In HIP header, Checksum field is set to zero.
	o In HIP header, the Header Length field value is calculated to the		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		beginning of the HMAC_2 parameter and added with the length of the
	concatenated HOST_ID parameter length.		concatenated HOST_ID parameter length.
	o HOST_ID parameter is exactly in the form it was received in the R1		o HOST_ID parameter is exactly in the form it was received in the R1
	packet from the Responder.		packet from the Responder.
	skipping to change at page 82, line 15		skipping to change at page 83, 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 MUST also verify that the Initiator's HIT in		11. The implementation SHOULD also verify that the Initiator's HIT
	the I2 corresponds to the Host Identity sent in the I2.		in the I2 corresponds to the Host Identity sent in the I2.
			(Note: some middle-boxes may not able to make this
			verification.)
	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 87, line 17		skipping to change at page 88, line 17
	will trigger creating and establishing of a new HIP association,		will trigger creating and establishing of a new HIP association,
	starting with sending an I1.		starting with sending an I1.
	If there is no corresponding HIP association, the CLOSE packet is		If there is no corresponding HIP association, the CLOSE packet is
	dropped.		dropped.
	6.15. Processing CLOSE_ACK Packets		6.15. Processing CLOSE_ACK Packets
	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_RESPONSE_SIGNED in response to the
	ECHO_REQUEST_SIGNED).		sent 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. Handling State Loss		6.16. Handling State Loss
	In the case of system crash and unanticipated state loss, the system		In the case of system crash and unanticipated state loss, the system
	SHOULD delete the corresponding HIP state, including the keying		SHOULD delete the corresponding HIP state, including the keying
	skipping to change at page 90, line 48		skipping to change at page 91, line 48
	Initiator can use this to validate the R1 HIP packet.		Initiator can use this to validate the R1 HIP packet.
	Likewise, if the Initiator's HI is in a secure DNS zone, a trusted		Likewise, if the Initiator's HI is in a secure DNS zone, a trusted
	certificate, or otherwise securely available, the Responder can		certificate, or otherwise securely available, the Responder can
	retrieve it after it gets the I2 HIP packet and validate that.		retrieve it after it gets the I2 HIP packet and validate that.
	However, since an Initiator may choose to use an anonymous HI, it		However, since an Initiator may choose to use an anonymous HI, it
	knowingly risks a MitM attack. The Responder may choose not to		knowingly risks a MitM attack. The Responder may choose not to
	accept a HIP exchange with an anonymous Initiator.		accept a HIP exchange with an anonymous Initiator.
	The HIP Opportunistic Mode concept has been introduced in this		The HIP Opportunistic Mode concept has been introduced in this
	document, but this document does not specify the details of such a		document, but this document does not specify what the semantics of
	connection set up (Section 4.1.6). There are certain security		such connection set up are for applications. There are certain
	concerns with opportunistic mode, and they must be addressed in a		concerns with opportunistic mode, as discussed in Section 4.1.6.
	separate document if such a mode will be used.
	NOTIFY messages are used only for informational purposes and they are		NOTIFY messages are used only for informational purposes and they are
	unacknowledged. A HIP implementation cannot rely solely on the		unacknowledged. A HIP implementation cannot rely solely on the
	information received in a NOTIFY message because the packet may have		information received in a NOTIFY message because the packet may have
	been replayed. It SHOULD NOT change any state information based		been replayed. It SHOULD NOT change any state information based
	purely on a received NOTIFY message.		purely on a received NOTIFY message.
	Since not all hosts will ever support HIP, ICMP 'Destination Protocol		Since not all hosts will ever support HIP, ICMP 'Destination Protocol
	Unreachable' are to be expected and present a DoS attack. Against an		Unreachable' are to be expected and present a DoS attack. Against an
	Initiator, the attack would look like the Responder does not support		Initiator, the attack would look like the Responder does not support
End of changes. 21 change blocks.
	140 lines changed or deleted		195 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/