draft-ietf-hip-rfc5205-bis-00.txt		draft-ietf-hip-rfc5205-bis-01.txt
	Network Working Group J. Laganier		Network Working Group J. Laganier
	Internet-Draft QUALCOMM Inc.		Internet-Draft Juniper Networks
	Obsoletes: 5205 (if approved) August 20, 2010		Obsoletes: 5205 (if approved) March 14, 2011
	Intended status: Standards Track		Intended status: Standards Track
	Expires: February 21, 2011		Expires: September 15, 2011
	Host Identity Protocol (HIP) Domain Name System (DNS) Extension		Host Identity Protocol (HIP) Domain Name System (DNS) Extension
	draft-ietf-hip-rfc5205-bis-00		draft-ietf-hip-rfc5205-bis-01
	Abstract		Abstract
	This document specifies a new resource record (RR) for the Domain		This document specifies a new resource record (RR) for the Domain
	Name System (DNS), and how to use it with the Host Identity Protocol		Name System (DNS), and how to use it with the Host Identity Protocol
	(HIP). This RR allows a HIP node to store in the DNS its Host		(HIP). This RR allows a HIP node to store in the DNS its Host
	Identity (HI, the public component of the node public-private key		Identity (HI, the public component of the node public-private key
	pair), Host Identity Tag (HIT, a truncated hash of its public key),		pair), Host Identity Tag (HIT, a truncated hash of its public key),
	and the Domain Names of its rendezvous servers (RVSs).		and the Domain Names of its rendezvous servers (RVSs).
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 21, 2011.		This Internet-Draft will expire on September 15, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 4		skipping to change at page 2, line 36
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . . 12		8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . . 12
	8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . . 13		8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . . 13
	8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 13		8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	12.1. Normative references . . . . . . . . . . . . . . . . . . . 14		12.1. Normative references . . . . . . . . . . . . . . . . . . . 14
	12.2. Informative references . . . . . . . . . . . . . . . . . . 15		12.2. Informative references . . . . . . . . . . . . . . . . . . 15
			Appendix A. Changes from RFC 5205 . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	This document specifies a new resource record (RR) for the Domain		This document specifies a new resource record (RR) for the Domain
	Name System (DNS) [RFC1034], and how to use it with the Host Identity		Name System (DNS) [RFC1034], and how to use it with the Host Identity
	Protocol (HIP) [RFC5201]. This RR allows a HIP node to store in the		Protocol (HIP) [I-D.ietf-hip-rfc5201-bis]. This RR allows a HIP node
	DNS its Host Identity (HI, the public component of the node public-		to store in the DNS its Host Identity (HI, the public component of
	private key pair), Host Identity Tag (HIT, a truncated hash of its		the node public-private key pair), Host Identity Tag (HIT, a
	HI), and the Domain Names of its rendezvous servers (RVSs) [RFC5204].		truncated hash of its HI), and the Domain Names of its rendezvous
			servers (RVSs) [I-D.ietf-hip-rfc5204-bis].
	Currently, most of the Internet applications that need to communicate		Currently, most of the Internet applications that need to communicate
	with a remote host first translate a domain name (often obtained via		with a remote host first translate a domain name (often obtained via
	user input) into one or more IP address(es). This step occurs prior		user input) into one or more IP address(es). This step occurs prior
	to communication with the remote host, and relies on a DNS lookup.		to communication with the remote host, and relies on a DNS lookup.
	With HIP, IP addresses are intended to be used mostly for on-the-wire		With HIP, IP addresses are intended to be used mostly for on-the-wire
	communication between end hosts, while most Upper Layer Protocols		communication between end hosts, while most Upper Layer Protocols
	(ULP) and applications use HIs or HITs instead (ICMP might be an		(ULP) and applications use HIs or HITs instead (ICMP might be an
	example of an ULP not using them). Consequently, we need a means to		example of an ULP not using them). Consequently, we need a means to
	translate a domain name into an HI. Using the DNS for this		translate a domain name into an HI. Using the DNS for this
	translation is pretty straightforward: We define a new HIP resource		translation is pretty straightforward: We define a new HIP resource
	record. Upon query by an application or ULP for a name to IP address		record. Upon query by an application or ULP for a name to IP address
	lookup, the resolver would then additionally perform a name to HI		lookup, the resolver would then additionally perform a name to HI
	lookup, and use it to construct the resulting HI to IP address		lookup, and use it to construct the resulting HI to IP address
	mapping (which is internal to the HIP layer). The HIP layer uses the		mapping (which is internal to the HIP layer). The HIP layer uses the
	HI to IP address mapping to translate HIs and HITs into IP addresses		HI to IP address mapping to translate HIs and HITs into IP addresses
	and vice versa.		and vice versa.
	The HIP Rendezvous Extension [RFC5204] allows a HIP node to be		The HIP Rendezvous Extension [I-D.ietf-hip-rfc5204-bis] allows a HIP
	reached via the IP address(es) of a third party, the node's		node to be reached via the IP address(es) of a third party, the
	rendezvous server (RVS). An Initiator willing to establish a HIP		node's rendezvous server (RVS). An Initiator willing to establish a
	association with a Responder served by an RVS would typically		HIP association with a Responder served by an RVS would typically
	initiate a HIP exchange by sending an I1 towards the RVS IP address		initiate a HIP exchange by sending an I1 towards the RVS IP address
	rather than towards the Responder IP address. Consequently, we need		rather than towards the Responder IP address. Consequently, we need
	a means to find the name of a rendezvous server for a given host		a means to find the name of a rendezvous server for a given host
	name.		name.
	This document introduces the new HIP DNS resource record to store the		This document introduces the new HIP DNS resource record to store the
	Rendezvous Server (RVS), Host Identity (HI), and Host Identity Tag		Rendezvous Server (RVS), Host Identity (HI), and Host Identity Tag
	(HIT) information.		(HIT) information.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	skipping to change at page 4, line 42		skipping to change at page 4, line 42
	middle attacks on the HIP exchange. To prevent these attacks, it is		middle attacks on the HIP exchange. To prevent these attacks, it is
	recommended that the Initiator first obtain the HI of the Responder,		recommended that the Initiator first obtain the HI of the Responder,
	and then initiate the exchange. This can be done, for example,		and then initiate the exchange. This can be done, for example,
	through manual configuration or DNS lookups. Hence, a new HIP RR is		through manual configuration or DNS lookups. Hence, a new HIP RR is
	introduced.		introduced.
	When a HIP node is frequently changing its IP address(es), the		When a HIP node is frequently changing its IP address(es), the
	natural DNS latency for propagating changes may prevent it from		natural DNS latency for propagating changes may prevent it from
	publishing its new IP address(es) in the DNS. For solving this		publishing its new IP address(es) in the DNS. For solving this
	problem, the HIP Architecture [RFC4423] introduces rendezvous servers		problem, the HIP Architecture [RFC4423] introduces rendezvous servers
	(RVSs) [RFC5204]. A HIP host uses a rendezvous server as a		(RVSs) [I-D.ietf-hip-rfc5204-bis]. A HIP host uses a rendezvous
	rendezvous point to maintain reachability with possible HIP		server as a rendezvous point to maintain reachability with possible
	initiators while moving [RFC5206]. Such a HIP node would publish in		HIP initiators while moving [RFC5206]. Such a HIP node would publish
	the DNS its RVS domain name(s) in a HIP RR, while keeping its RVS up-		in the DNS its RVS domain name(s) in a HIP RR, while keeping its RVS
	to-date with its current set of IP addresses.		up-to-date with its current set of IP addresses.
	When a HIP node wants to initiate a HIP exchange with a Responder, it		When a HIP node wants to initiate a HIP exchange with a Responder, it
	will perform a number of DNS lookups. Depending on the type of		will perform a number of DNS lookups. Depending on the type of
	implementation, the order in which those lookups will be issued may		implementation, the order in which those lookups will be issued may
	vary. For instance, implementations using HIT in APIs may typically		vary. For instance, implementations using HIT in APIs may typically
	first query for HIP resource records at the Responder FQDN, while		first query for HIP resource records at the Responder FQDN, while
	those using an IP address in APIs may typically first query for A		those using an IP address in APIs may typically first query for A
	and/or AAAA resource records.		and/or AAAA resource records.
	In the following, we assume that the Initiator first queries for HIP		In the following, we assume that the Initiator first queries for HIP
	skipping to change at page 8, line 14		skipping to change at page 8, line 14
	4. Overview of Using the DNS with HIP		4. Overview of Using the DNS with HIP
	4.1. Storing HI, HIT, and RVS in the DNS		4.1. Storing HI, HIT, and RVS in the DNS
	For any HIP node, its Host Identity (HI), the associated Host		For any HIP node, its Host Identity (HI), the associated Host
	Identity Tag (HIT), and the FQDN of its possible RVSs can be stored		Identity Tag (HIT), and the FQDN of its possible RVSs can be stored
	in a DNS HIP RR. Any conforming implementation may store a Host		in a DNS HIP RR. Any conforming implementation may store a Host
	Identity (HI) and its associated Host Identity Tag (HIT) in a DNS HIP		Identity (HI) and its associated Host Identity Tag (HIT) in a DNS HIP
	RDATA format. HI and HIT are defined in Section 3 of the HIP		RDATA format. HI and HIT are defined in Section 3 of the HIP
	specification [RFC5201].		specification [I-D.ietf-hip-rfc5201-bis].
	Upon return of a HIP RR, a host MUST always calculate the HI-		Upon return of a HIP RR, a host MUST always calculate the HI-
	derivative HIT to be used in the HIP exchange, as specified in		derivative HIT to be used in the HIP exchange, as specified in
	Section 3 of the HIP specification [RFC5201], while the HIT possibly		Section 3 of the HIP specification [I-D.ietf-hip-rfc5201-bis], while
	embedded along SHOULD only be used as an optimization (e.g., table		the HIT possibly embedded along SHOULD only be used as an
	lookup).		optimization (e.g., table lookup).
	The HIP resource record may also contain one or more domain name(s)		The HIP resource record may also contain one or more domain name(s)
	of rendezvous server(s) towards which HIP I1 packets might be sent to		of rendezvous server(s) towards which HIP I1 packets might be sent to
	trigger the establishment of an association with the entity named by		trigger the establishment of an association with the entity named by
	this resource record [RFC5204].		this resource record [I-D.ietf-hip-rfc5204-bis].
	The rendezvous server field of the HIP resource record stored at a		The rendezvous server field of the HIP resource record stored at a
	given owner name MAY include the owner name itself. A semantically		given owner name MAY include the owner name itself. A semantically
	equivalent situation occurs if no rendezvous server is present in the		equivalent situation occurs if no rendezvous server is present in the
	HIP resource record stored at that owner name. Such situations occur		HIP resource record stored at that owner name. Such situations occur
	in two cases:		in two cases:
	o The host is mobile, and the A and/or AAAA resource record(s)		o The host is mobile, and the A and/or AAAA resource record(s)
	stored at its host name contain the IP address(es) of its		stored at its host name contain the IP address(es) of its
	rendezvous server rather than its own one.		rendezvous server rather than its own one.
	skipping to change at page 13, line 7		skipping to change at page 13, line 7
	peer's public key (the HI) and its secure hash (the HIT). Both of		peer's public key (the HI) and its secure hash (the HIT). Both of
	these are not sensitive to attacks where an adversary gains knowledge		these are not sensitive to attacks where an adversary gains knowledge
	of them. However, an attacker that is able to mount an active attack		of them. However, an attacker that is able to mount an active attack
	on the DNS, i.e., tampers with this HIP RR (e.g., using DNS		on the DNS, i.e., tampers with this HIP RR (e.g., using DNS
	spoofing), is able to mount Man-in-the-Middle attacks on the		spoofing), is able to mount Man-in-the-Middle attacks on the
	cryptographic core of the eventual HIP exchange (Responder's HIP RR		cryptographic core of the eventual HIP exchange (Responder's HIP RR
	rewritten by the attacker).		rewritten by the attacker).
	The HIP RR may contain a rendezvous server domain name resolved into		The HIP RR may contain a rendezvous server domain name resolved into
	a destination IP address where the named peer is reachable by an I1,		a destination IP address where the named peer is reachable by an I1,
	as per the HIP Rendezvous Extension [RFC5204]. Thus, an attacker		as per the HIP Rendezvous Extension [I-D.ietf-hip-rfc5204-bis].
	able to tamper with this RR is able to redirect I1 packets sent to		Thus, an attacker able to tamper with this RR is able to redirect I1
	the named peer to a chosen IP address for DoS or MitM attacks. Note		packets sent to the named peer to a chosen IP address for DoS or MitM
	that this kind of attack is not specific to HIP and exists		attacks. Note that this kind of attack is not specific to HIP and
	independently of whether or not HIP and the HIP RR are used. Such an		exists independently of whether or not HIP and the HIP RR are used.
	attacker might tamper with A and AAAA RRs as well.		Such an attacker might tamper with A and AAAA RRs as well.
	An attacker might obviously use these two attacks in conjunction: It		An attacker might obviously use these two attacks in conjunction: It
	will replace the Responder's HI and RVS IP address by its own in a		will replace the Responder's HI and RVS IP address by its own in a
	spoofed DNS packet sent to the Initiator HI, then redirect all		spoofed DNS packet sent to the Initiator HI, then redirect all
	exchanged packets to him and mount a MitM on HIP. In this case, HIP		exchanged packets to him and mount a MitM on HIP. In this case, HIP
	won't provide confidentiality nor Initiator HI protection from		won't provide confidentiality nor Initiator HI protection from
	eavesdroppers.		eavesdroppers.
	8.2. Hash and HITs Collisions		8.2. Hash and HITs Collisions
	skipping to change at page 14, line 28		skipping to change at page 14, line 28
	As usual in the IETF, this document is the result of a collaboration		As usual in the IETF, this document is the result of a collaboration
	between many people. The authors would like to thank the author		between many people. The authors would like to thank the author
	(Michael Richardson), contributors, and reviewers of the IPSECKEY RR		(Michael Richardson), contributors, and reviewers of the IPSECKEY RR
	[RFC4025] specification, after which this document was framed. The		[RFC4025] specification, after which this document was framed. The
	authors would also like to thank the following people, who have		authors would also like to thank the following people, who have
	provided thoughtful and helpful discussions and/or suggestions, that		provided thoughtful and helpful discussions and/or suggestions, that
	have helped improve this document: Jeff Ahrenholz, Rob Austein, Hannu		have helped improve this document: Jeff Ahrenholz, Rob Austein, Hannu
	Flinck, Olafur Gudmundsson, Tom Henderson, Peter Koch, Olaf Kolkman,		Flinck, Olafur Gudmundsson, Tom Henderson, Peter Koch, Olaf Kolkman,
	Miika Komu, Andrew McGregor, Erik Nordmark, and Gabriel Montenegro.		Miika Komu, Andrew McGregor, Erik Nordmark, and Gabriel Montenegro.
	Some parts of this document stem from the HIP specification		Some parts of this document stem from the HIP specification
	[RFC5201].		[I-D.ietf-hip-rfc5201-bis].
	12. References		12. References
	12.1. Normative references		12.1. Normative references
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and
	STD 13, RFC 1034, November 1987.		T. Henderson, "Host Identity Protocol
			Version 2 (HIPv2)",
			draft-ietf-hip-rfc5201-bis-05 (work in
			progress), March 2011.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host
	specification", STD 13, RFC 1035, November 1987.		Identity Protocol (HIP) Rendezvous
			Extension", draft-ietf-hip-rfc5204-bis-00
			(work in progress), August 2010.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC1034] Mockapetris, P., "Domain names - concepts
	Requirement Levels", BCP 14, RFC 2119, March 1997.		and facilities", STD 13, RFC 1034,
			November 1987.
	[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS		[RFC1035] Mockapetris, P., "Domain names -
	Specification", RFC 2181, July 1997.		implementation and specification",
			STD 13, RFC 1035, November 1987.
	[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,		[RFC2119] Bradner, S., "Key words for use in RFCs
	"DNS Extensions to Support IP Version 6", RFC 3596,		to Indicate Requirement Levels", BCP 14,
	October 2003.		RFC 2119, March 1997.
	[RFC4025] Richardson, M., "A Method for Storing IPsec Keying		[RFC2181] Elz, R. and R. Bush, "Clarifications to
	Material in DNS", RFC 4025, March 2005.		the DNS Specification", RFC 2181,
			July 1997.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC3596] Thomson, S., Huitema, C., Ksinant, V.,
	Rose, "DNS Security Introduction and Requirements",		and M. Souissi, "DNS Extensions to
	RFC 4033, March 2005.		Support IP Version 6", RFC 3596,
			October 2003.
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4025] Richardson, M., "A Method for Storing
	Rose, "Resource Records for the DNS Security Extensions",		IPsec Keying Material in DNS", RFC 4025,
	RFC 4034, March 2005.		March 2005.
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M.,
	Rose, "Protocol Modifications for the DNS Security		Massey, D., and S. Rose, "DNS Security
	Extensions", RFC 4035, March 2005.		Introduction and Requirements", RFC 4033,
			March 2005.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4034] Arends, R., Austein, R., Larson, M.,
	Encodings", RFC 4648, October 2006.		Massey, D., and S. Rose, "Resource
			Records for the DNS Security Extensions",
			RFC 4034, March 2005.
	[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.		[RFC4035] Arends, R., Austein, R., Larson, M.,
	Henderson, "Host Identity Protocol", RFC 5201, April 2008.		Massey, D., and S. Rose, "Protocol
			Modifications for the DNS Security
			Extensions", RFC 4035, March 2005.
	[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)		[RFC4648] Josefsson, S., "The Base16, Base32, and
	Rendezvous Extension", RFC 5204, April 2008.		Base64 Data Encodings", RFC 4648,
			October 2006.
	12.2. Informative references		12.2. Informative references
	[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System		[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the
	(DNS)", RFC 2536, March 1999.		Domain Name System (DNS)", RFC 2536,
			March 1999.
	[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain		[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA
	Name System (DNS)", RFC 3110, May 2001.		KEYs in the Domain Name System (DNS)",
			RFC 3110, May 2001.
	[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain		[RFC3833] Atkins, D. and R. Austein, "Threat
	Name System (DNS)", RFC 3833, August 2004.		Analysis of the Domain Name System
			(DNS)", RFC 3833, August 2004.
	[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol		[RFC4423] Moskowitz, R. and P. Nikander, "Host
	(HIP) Architecture", RFC 4423, May 2006.		Identity Protocol (HIP) Architecture",
			RFC 4423, May 2006.
	[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol		[RFC5205] Nikander, P. and J. Laganier, "Host
	(HIP) Domain Name System (DNS) Extensions", RFC 5205,		Identity Protocol (HIP) Domain Name
	April 2008.		System (DNS) Extensions", RFC 5205,
			April 2008.
	[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming		[RFC5206] Henderson, T., Ed., "End-Host Mobility
	with the Host Identity Protocol", RFC 5206, April 2008.		and Multihoming with the Host Identity
			Protocol", RFC 5206, April 2008.
			Appendix A. Changes from RFC 5205
			o Updated HIP references to revised HIP specifications.
	Author's Address		Author's Address
	Julien Laganier		Julien Laganier
	QUALCOMM Incorporated		Juniper Networks
	5775 Morehouse Drive		1094 North Mathilda Avenue
	San Diego, CA 92121		Sunnyvale, CA 94089
	USA		USA
	Phone: +1 858 858 3538		Phone: +1 408 936 0385
	EMail: julienl@qualcomm.com		EMail: julien.ietf@gmail.com
End of changes. 34 change blocks.
	75 lines changed or deleted		102 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/