draft-ietf-hip-rfc5205-bis-06.txt   draft-ietf-hip-rfc5205-bis-07.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) January 16, 2015 Obsoletes: 5205 (if approved) June 10, 2015
Intended status: Standards Track Intended status: Standards Track
Expires: July 20, 2015 Expires: December 12, 2015
Host Identity Protocol (HIP) Domain Name System (DNS) Extension Host Identity Protocol (HIP) Domain Name System (DNS) Extension
draft-ietf-hip-rfc5205-bis-06 draft-ietf-hip-rfc5205-bis-07
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 July 20, 2015. This Internet-Draft will expire on December 12, 2015.
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 13 skipping to change at page 2, line 13
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Simple Static Singly Homed End-Host . . . . . . . . . . . 5 3.1. Simple Static Single Homed End-Host . . . . . . . . . . . 5
3.2. Mobile end-host . . . . . . . . . . . . . . . . . . . . . 6 3.2. Mobile end-host . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Using the DNS with HIP . . . . . . . . . . . . . 7 4. Overview of Using the DNS with HIP . . . . . . . . . . . . . 7
4.1. Storing HI, HIT, and RVS in the DNS . . . . . . . . . . . 7 4.1. Storing HI, HIT, and RVS in the DNS . . . . . . . . . . . 7
4.2. Initiating Connections Based on DNS Names . . . . . . . . 8 4.2. Initiating Connections Based on DNS Names . . . . . . . . 8
5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 8 5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 9
5.1. HIT Length Format . . . . . . . . . . . . . . . . . . . . 9 5.1. HIT Length Format . . . . . . . . . . . . . . . . . . . . 10
5.2. PK Algorithm Format . . . . . . . . . . . . . . . . . . . 9 5.2. PK Algorithm Format . . . . . . . . . . . . . . . . . . . 10
5.3. PK Length Format . . . . . . . . . . . . . . . . . . . . 9 5.3. PK Length Format . . . . . . . . . . . . . . . . . . . . 10
5.4. HIT Format . . . . . . . . . . . . . . . . . . . . . . . 10 5.4. HIT Format . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Public Key Format . . . . . . . . . . . . . . . . . . . . 10 5.5. Public Key Format . . . . . . . . . . . . . . . . . . . . 10
5.6. Rendezvous Servers Format . . . . . . . . . . . . . . . . 10 5.6. Rendezvous Servers Format . . . . . . . . . . . . . . . . 10
6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . 10 6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . 11
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . 13
8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . 13 8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . 13
8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . 15
Appendix A. Changes from RFC 5205 . . . . . . . . . . . . . . . 16 Appendix A. Changes from RFC 5205 . . . . . . . . . . . . . . . 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) [I-D.ietf-hip-rfc5201-bis]. This RR allows a HIP node
to store in the DNS its Host Identity (HI, the public component of to store in the DNS its Host Identity (HI, the public component of
the node public-private key pair), Host Identity Tag (HIT, a the node public-private key pair), Host Identity Tag (HIT, a
truncated hash of its HI), and the Domain Names of its rendezvous truncated hash of its HI), and the Domain Names of its rendezvous
servers (RVSs) [I-D.ietf-hip-rfc5204-bis]. servers (RVSs) [I-D.ietf-hip-rfc5204-bis].
skipping to change at page 5, line 20 skipping to change at page 5, line 20
plain IP, it would send out more queries for A and AAAA types at the plain IP, it would send out more queries for A and AAAA types at the
Responder's FQDN. Responder's FQDN.
Depending on the combinations of answers, the situations described in Depending on the combinations of answers, the situations described in
Section 3.1 and Section 3.2 can occur. Section 3.1 and Section 3.2 can occur.
Note that storing HIP RR information in the DNS at an FQDN that is Note that storing HIP RR information in the DNS at an FQDN that is
assigned to a non-HIP node might have ill effects on its reachability assigned to a non-HIP node might have ill effects on its reachability
by HIP nodes. by HIP nodes.
3.1. Simple Static Singly Homed End-Host 3.1. Simple Static Single Homed End-Host
A HIP node (R) with a single static network attachment, wishing to be A HIP node (R) with a single static network attachment, wishing to be
reachable by reference to its FQDN (www.example.com), would store in reachable by reference to its FQDN (www.example.com), would store in
the DNS, in addition to its IP address(es) (IP-R), its Host Identity the DNS, in addition to its IP address(es) (IP-R), its Host Identity
(HI-R) and Host Identity Tag (HIT-R) in a HIP resource record. (HI-R) and Host Identity Tag (HIT-R) in a HIP resource record.
An Initiator willing to associate with a node would typically issue An Initiator willing to associate with a node would typically issue
the following queries: the following queries:
o QNAME=www.example.com, QTYPE=HIP o QNAME=www.example.com, QTYPE=HIP
skipping to change at page 8, line 31 skipping to change at page 8, line 31
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.
o The host is stationary, and can be reached directly at the IP o The host is stationary, and can be reached directly at the IP
address(es) contained in the A and/or AAAA resource record(s) address(es) contained in the A and/or AAAA resource record(s)
stored at its host name. This is a degenerated case of rendezvous stored at its host name. This is a degenerate case of rendezvous
service where the host somewhat acts as a rendezvous server for service where the host somewhat acts as a rendezvous server for
itself. itself.
An RVS receiving such an I1 would then relay it to the appropriate An RVS receiving such an I1 would then relay it to the appropriate
Responder (the owner of the I1 receiver HIT). The Responder will Responder (the owner of the I1 receiver HIT). The Responder will
then complete the exchange with the Initiator, typically without then complete the exchange with the Initiator, typically without
ongoing help from the RVS. ongoing help from the RVS.
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
them. When the number of seconds that passed since the record was
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
access to the record is necessary to initiate communication with the
entity to which the record corresponds, a new query MUST be be made
to retrieve a fresh copy of the record.
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
between multiple RRs when more than one is returned. The RVS
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
associated with the HI being used, when multiple choices are
present."
5. HIP RR Storage Format 5. HIP RR Storage Format
The RDATA for a HIP RR consists of a public key algorithm type, the The RDATA for a HIP RR consists of a public key algorithm type, the
HIT length, a HIT, a public key, and optionally one or more HIT length, a HIT, a public key, and optionally one or more
rendezvous server(s). rendezvous server(s).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HIT length | PK algorithm | PK length | | HIT length | PK algorithm | PK length |
skipping to change at page 13, line 41 skipping to change at page 14, line 16
based solely on a HIT retrieved from the DNS, but SHOULD rather use based solely on a HIT retrieved from the DNS, but SHOULD rather use
HI-based authentication. HI-based authentication.
8.3. DNSSEC 8.3. DNSSEC
In the absence of DNSSEC, the HIP RR is subject to the threats In the absence of DNSSEC, the HIP RR is subject to the threats
described in RFC 3833 [RFC3833]. described in RFC 3833 [RFC3833].
9. IANA Considerations 9. IANA Considerations
IANA has allocated one new RR type code (55) for the HIP RR from the IANA is requested to replace references to [RFC5205] by references to
standard RR type space. this document in the the DNS RR type code registry.
IANA does not need to open a new registry for public key algorithms
of the HIP RR because the HIP RR reuses "algorithms types" defined
for the IPSECKEY RR [RFC4025]. Presently defined values are:
0 is reserved
1 is DSA IANA is requested to allocate the following algorithm type in the
2 is RSA IPSECKEY RR [RFC4025] registry:
[IANA-TBD] is ECDSA [IANA-TBD] is ECDSA
10. Contributors 10. Contributors
Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an
earlier, experimental version of this specification [RFC5205]. earlier, experimental version of this specification [RFC5205].
11. Acknowledgments 11. Acknowledgments
skipping to change at page 16, line 12 skipping to change at page 17, line 12
[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).
o Clarified that new query must be made when the time that passed
since a RR was retrieved exceeds the TTL of the RR.
o Added considerations related to multiple HIP RRs being associated
with a single name.
Author's Address Author's Address
Julien Laganier Julien Laganier
Luminate Wireless, Inc. Luminate Wireless, Inc.
Cupertino, CA Cupertino, CA
USA USA
EMail: julien.ietf@gmail.com EMail: julien.ietf@gmail.com
 End of changes. 16 change blocks. 
27 lines changed or deleted 44 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/