draft-ietf-hip-rfc5205-bis-07.txt   draft-ietf-hip-rfc5205-bis-08.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft Luminate Wireless, Inc. Internet-Draft Luminate Wireless, Inc.
Obsoletes: 5205 (if approved) June 10, 2015 Obsoletes: 5205 (if approved) December 14, 2015
Intended status: Standards Track Intended status: Standards Track
Expires: December 12, 2015 Expires: June 16, 2016
Host Identity Protocol (HIP) Domain Name System (DNS) Extension Host Identity Protocol (HIP) Domain Name System (DNS) Extension
draft-ietf-hip-rfc5205-bis-07 draft-ietf-hip-rfc5205-bis-08
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). This document and the Domain Names of its rendezvous servers (RVSs). This document
obsoletes RFC5205. obsoletes RFC5205.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 December 12, 2015. This Internet-Draft will expire on June 16, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . 13 8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . 13
8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . 13 8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . 13
8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . 16
Appendix A. Changes from RFC 5205 . . . . . . . . . . . . . . . 17 Appendix A. Changes from RFC 5205 . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
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) [I-D.ietf-hip-rfc5201-bis]. This RR allows a HIP node Protocol (HIP) [RFC7401]. This RR allows a HIP node to store in the
to store in the DNS its Host Identity (HI, the public component of DNS its Host Identity (HI, the public component of the node public-
the node public-private key pair), Host Identity Tag (HIT, a private key pair), Host Identity Tag (HIT, a truncated hash of its
truncated hash of its HI), and the Domain Names of its rendezvous HI), and the Domain Names of its rendezvous servers (RVSs)
servers (RVSs) [I-D.ietf-hip-rfc5204-bis]. [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
skipping to change at page 8, line 6 skipping to change at page 8, line 6
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 [I-D.ietf-hip-rfc5201-bis]. specification [RFC7401].
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 [I-D.ietf-hip-rfc5201-bis], while Section 3 of the HIP specification [RFC7401], while the HIT possibly
the HIT possibly embedded along SHOULD only be used as an embedded along SHOULD only be used as an optimization (e.g., table
optimization (e.g., table lookup). 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 [I-D.ietf-hip-rfc5204-bis]. 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
skipping to change at page 8, line 49 skipping to change at page 8, line 49
4.2. Initiating Connections Based on DNS Names 4.2. Initiating Connections Based on DNS Names
On a HIP node, a Host Identity Protocol exchange SHOULD be initiated On a HIP node, a Host Identity Protocol exchange SHOULD be initiated
whenever a ULP attempts to communicate with an entity and the DNS whenever a ULP attempts to communicate with an entity and the DNS
lookup returns HIP resource records. lookup returns HIP resource records.
The HIP resource records have a Time To Live (TTL) associated with The HIP resource records have a Time To Live (TTL) associated with
them. When the number of seconds that passed since the record was them. When the number of seconds that passed since the record was
retrieved exceeds the record's TTL, the record MUST be considered to retrieved exceeds the record's TTL, the record MUST be considered to
be no longer valid and deleted by the entiry that retrieved it. If be no longer valid and deleted by the entity that retrieved it. If
access to the record is necessary to initiate communication with the access to the record is necessary to initiate communication with the
entity to which the record corresponds, a new query MUST be be made entity to which the record corresponds, a new query MUST be be made
to retrieve a fresh copy of the record. to retrieve a fresh copy of the record.
There may be multiple HIP RRs associated with a single name. It is There may be multiple HIP RRs associated with a single name. It is
outside the scope of this specification as to how a host chooses from outside the scope of this specification as to how a host chooses from
between multiple RRs when more than one is returned. The RVS between multiple RRs when more than one is returned. The RVS
information may be copied and aligned across multiple RRs, or may be information may be copied and aligned across multiple RRs, or may be
different for each one; a host MUST check that the RVS used is different for each one; a host MUST check that the RVS used is
associated with the HI being used, when multiple choices are associated with the HI being used, when multiple choices are
skipping to change at page 11, line 34 skipping to change at page 11, line 34
of the public key. The encoding MUST NOT contain whitespace(s) to of the public key. The encoding MUST NOT contain whitespace(s) to
distinguish it from the Rendezvous Servers field. distinguish it from the Rendezvous Servers field.
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 containing no thanks to the Public key field representation containing no
whitespaces. whitespaces.
The Rendezvous Servers field is represented by one or more domain The Rendezvous Servers field is represented by one or more domain
name(s) separated by whitespace(s). name(s) separated by whitespace(s).
The complete representation of the HPIHI record is: The complete representation of the HIP record is:
IN HIP ( pk-algorithm IN HIP ( pk-algorithm
base16-encoded-hit base16-encoded-hit
base64-encoded-public-key base64-encoded-public-key
rendezvous-server[1] rendezvous-server[1]
... ...
rendezvous-server[n] ) rendezvous-server[n] )
When no RVSs are present, the representation of the HPIHI record is: When no RVSs are present, the representation of the HIP record is:
IN HIP ( pk-algorithm IN HIP ( pk-algorithm
base16-encoded-hit base16-encoded-hit
base64-encoded-public-key ) base64-encoded-public-key )
7. Examples 7. Examples
In the examples below, the public key field containing no whitespace In the examples below, the public key field containing no whitespace
is wrapped since it does not fit in a single line of this document. is wrapped since it does not fit in a single line of this document.
skipping to change at page 14, line 41 skipping to change at page 14, line 41
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
[I-D.ietf-hip-rfc5201-bis]. [RFC7401]. Finally, thanks Sheng Jiang for performing the Internet
Area Directorate review of this document in the course of the
publication process.
12. References 12. References
12.1. Normative references 12.1. Normative references
[I-D.ietf-hip-rfc5201-bis]
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
hip-rfc5201-bis-20 (work in progress), October 2014.
[I-D.ietf-hip-rfc5204-bis] [I-D.ietf-hip-rfc5204-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rfc5204-bis-05 (work Rendezvous Extension", draft-ietf-hip-rfc5204-bis-06 (work
in progress), December 2014. in progress), June 2015.
[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, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[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, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997. Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<http://www.rfc-editor.org/info/rfc2181>.
[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. DOI 10.17487/RFC3596, October 2003,
<http://www.rfc-editor.org/info/rfc3596>.
[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, DOI 10.17487/RFC4025, March
2005, <http://www.rfc-editor.org/info/rfc4025>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements",
4033, March 2005. RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
Signature Algorithm (DSA) for DNSSEC", RFC 6605, April Signature Algorithm (DSA) for DNSSEC", RFC 6605,
2012. DOI 10.17487/RFC6605, April 2012,
<http://www.rfc-editor.org/info/rfc6605>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>.
12.2. Informative references 12.2. Informative references
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
(DNS)", RFC 2536, March 1999. System (DNS)", RFC 2536, DOI 10.17487/RFC2536, March 1999,
<http://www.rfc-editor.org/info/rfc2536>.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
Name System (DNS)", RFC 3110, May 2001. Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110,
May 2001, <http://www.rfc-editor.org/info/rfc3110>.
[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, DOI 10.17487/RFC3833, August
2004, <http://www.rfc-editor.org/info/rfc3833>.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May
2006, <http://www.rfc-editor.org/info/rfc4423>.
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions", RFC 5205, (HIP) Domain Name System (DNS) Extensions", RFC 5205,
April 2008. DOI 10.17487/RFC5205, April 2008,
<http://www.rfc-editor.org/info/rfc5205>.
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming [RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming
with the Host Identity Protocol", RFC 5206, April 2008. with the Host Identity Protocol", RFC 5206, April 2008.
Appendix A. Changes from RFC 5205 Appendix A. Changes from RFC 5205
o Updated HIP references to revised HIP specifications. o Updated HIP references to revised HIP specifications.
o Extended DNS HIP RR to support for Host Identities based on o Extended DNS HIP RR to support for Host Identities based on
Elliptic Curve Digital Signature Algorithm (ECDSA). Elliptic Curve Digital Signature Algorithm (ECDSA).
 End of changes. 30 change blocks. 
45 lines changed or deleted 64 lines changed or added

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