draft-ietf-hip-dns-07.txt   draft-ietf-hip-dns-08.txt 
Network Working Group P. Nikander Network Working Group P. Nikander
Internet-Draft Ericsson Research Nomadic Lab Internet-Draft Ericsson Research Nomadic Lab
Expires: March 31, 2007 J. Laganier Expires: April 20, 2007 J. Laganier
DoCoMo Euro-Labs DoCoMo Euro-Labs
September 27, 2006 October 17, 2006
Host Identity Protocol (HIP) Domain Name System (DNS) Extensions Host Identity Protocol (HIP) Domain Name System (DNS) Extensions
draft-ietf-hip-dns-07 draft-ietf-hip-dns-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 March 31, 2007. This Internet-Draft will expire on April 20, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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
skipping to change at page 5, line 20 skipping to change at page 5, line 20
With HIP, most application and ULPs are unaware of the IP addresses With HIP, most application and ULPs are unaware of the IP addresses
used to carry packets on the wire. Consequently, a HIP node could used to carry packets on the wire. Consequently, a HIP node could
take advantage of having multiple IP addresses for fail-over, take advantage of having multiple IP addresses for fail-over,
redundancy, mobility, or renumbering, in a manner which is redundancy, mobility, or renumbering, in a manner which is
transparent to most ULPs and applications (because they are bound to transparent to most ULPs and applications (because they are bound to
HIs, hence they are agnostic to these IP address changes.) HIs, hence they are agnostic to these IP address changes.)
In these situations, a node wishing to be reachable by reference to In these situations, a node wishing to be reachable by reference to
its FQDN should store the following information in the DNS: its FQDN should store the following information in the DNS:
o A set of IP address(es) through A and AAAA RRs. o A set of IP address(es) through A [RFC1035] and AAAA [RFC3596]
RRs.
o A Host Identity (HI), Host Identity Tag (HIT) and possibly a set o A Host Identity (HI), Host Identity Tag (HIT) and possibly a set
of rendezvous server(s) (RVS) through HIP RRs. of rendezvous server(s) (RVS) through HIP RRs.
When a HIP node wants to initiate a communication with another HIP When a HIP node wants to initiate a communication with another HIP
node, it first needs to perform a HIP base exchange to set-up a HIP node, it first needs to perform a HIP base exchange to set-up a HIP
association towards its peer. Although such an exchange can be association towards its peer. Although such an exchange can be
initiated opportunistically, i.e., without prior knowledge of the initiated opportunistically, i.e., without prior knowledge of the
responder's HI, by doing so both nodes knowingly risk man-in-the- responder's HI, by doing so both nodes knowingly risk man-in-the-
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
dynamic DNS update latency may prevent it from publishing its new IP dynamic DNS update latency may prevent it from publishing its new IP
address(es) in the DNS. For solving this problem, the HIP address(es) in the DNS. For solving this problem, the HIP
architecture introduces rendezvous servers (RVS.) A HIP host uses a architecture [RFC4423] introduces rendezvous servers (RVS.) A HIP
rendezvous server as a rendezvous point, to maintain reachability host uses a rendezvous server as a rendezvous point, to maintain
with possible HIP initiators. Such a HIP node would publish in the reachability with possible HIP initiators while moving
DNS its RVS domain name(s) in a HIP RR, while keeping its RVS up-to- [I-D.ietf-hip-mm]. Such a HIP node would publish in the DNS its RVS
date with its current set of IP addresses. domain name(s) in a HIP RR, while keeping its RVS 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 the will perform a number of DNS lookups. Depending on the type of the
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 IP address in APIs may typically first query for A and/or those using IP address in APIs may typically first query for A and/or
AAAA resource records. 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 12, line 18 skipping to change at page 12, line 18
data master file. data master file.
The HIT length field is not represented as it is implicitly known The HIT length field is not represented as it is implicitly known
thanks to the HIT field representation. thanks to the HIT field representation.
The PK algorithm field is represented as unsigned integers. The PK algorithm field is represented as unsigned integers.
The PK length field is not represented as it is implicitly known The PK length field is not represented as it is implicitly known
thanks to the Public key field representation. thanks to the Public key field representation.
The HIT field is represented as the Base16 encoding [RFC3548] (a.k.a. The HIT field is represented as the Base16 encoding [RFC4648] (a.k.a.
hex or hexadecimal) of the HIT. The encoding MUST NOT contain hex or hexadecimal) of the HIT. The encoding MUST NOT contain
whitespace(s). whitespace(s).
The Public Key field is represented as the Base64 encoding [RFC3548] The Public Key field is represented as the Base64 encoding [RFC4648]
of the public key. The encoding MAY contain whitespace(s), and such of the public key. The encoding MAY contain whitespace(s), and such
whitespace(s) MUST be ignored. whitespace(s) MUST be ignored.
The Rendezvous servers field is represented by one or more The Rendezvous servers field is represented by one or more
uncompressed domain name(s) uncompressed domain name(s)
The complete representation of the HPIHI record is: The complete representation of the HPIHI record is:
IN HIP ( pk-algorithm IN HIP ( pk-algorithm
base16-encoded-hit base16-encoded-hit
skipping to change at page 14, line 22 skipping to change at page 14, line 22
In a manner similar to the IPSECKEY RR [RFC4025], the HIP DNS In a manner similar to the IPSECKEY RR [RFC4025], the HIP DNS
Extensions allows to provision two HIP nodes with the public keying Extensions allows to provision two HIP nodes with the public keying
material (HI) of their peer. These HIs will be subsequently used in material (HI) of their peer. These HIs will be subsequently used in
a key exchange between the peers. Hence, the HIP DNS Extensions a key exchange between the peers. Hence, the HIP DNS Extensions
introduce the same kind of threats that IPSECKEY does, plus threats introduce the same kind of threats that IPSECKEY does, plus threats
caused by the possibility given to a HIP node to initiate or accept a caused by the possibility given to a HIP node to initiate or accept a
HIP exchange using "opportunistic" or "unpublished initiator HI" HIP exchange using "opportunistic" or "unpublished initiator HI"
modes. modes.
A HIP node SHOULD obtain HIP RRs from a trusted party trough a secure A HIP node SHOULD obtain HIP RRs from a trusted party trough a secure
channel insuring proper data integrity of the RRs. DNSSEC [RFC2065] channel insuring proper data integrity of the RRs. DNSSEC [RFC4033]
provides such a secure channel. [RFC4034] [RFC4035] provides such a secure channel.
In the absence of a proper secure channel, both parties are In the absence of a proper secure channel, both parties are
vulnerable to MitM and DoS attacks, and unrelated parties might be vulnerable to MitM and DoS attacks, and unrelated parties might be
subject to DoS attacks as well. These threats are described in the subject to DoS attacks as well. These threats are described in the
following sections. following sections.
8.1. Attacker tampering with an insecure HIP RR 8.1. Attacker tampering with an insecure HIP RR
The HIP RR contains public keying material in the form of the named The HIP RR contains public keying material in the form of the named
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
skipping to change at page 18, line 15 skipping to change at page 18, line 15
11. References 11. References
11.1. Normative references 11.1. Normative references
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999. (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 KEYs in the Domain
Name System (DNS)", RFC 3110, May 2001. Name System (DNS)", RFC 3110, May 2001.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363,
August 2002.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596, "DNS Extensions to Support IP Version 6", RFC 3596,
October 2003. October 2003.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005. Material in DNS", RFC 4025, March 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[I-D.ietf-hip-base] [I-D.ietf-hip-base]
Moskowitz, R., "Host Identity Protocol", Moskowitz, R., "Host Identity Protocol",
draft-ietf-hip-base-06 (work in progress), June 2006. draft-ietf-hip-base-06 (work in progress), June 2006.
[I-D.ietf-hip-rvs] [I-D.ietf-hip-rvs]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rvs-05 (work in Rendezvous Extension", draft-ietf-hip-rvs-05 (work in
progress), June 2006. progress), June 2006.
11.2. Informative references 11.2. Informative references
[I-D.ietf-hip-arch] [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
Architecture", draft-ietf-hip-arch-03 (work in progress),
August 2005.
[I-D.ietf-hip-mm] [I-D.ietf-hip-mm]
Nikander, P., "End-Host Mobility and Multihoming with the Nikander, P., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-04 (work in Host Identity Protocol", draft-ietf-hip-mm-04 (work in
progress), June 2006. progress), June 2006.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004. Name System (DNS)", RFC 3833, August 2004.
Authors' Addresses Authors' Addresses
Pekka Nikander Pekka Nikander
Ericsson Research Nomadic Lab Ericsson Research Nomadic Lab
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
 End of changes. 14 change blocks. 
33 lines changed or deleted 33 lines changed or added

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