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/