--- 1/draft-ietf-hip-rfc5205-bis-06.txt 2015-06-10 19:15:03.803027681 -0700 +++ 2/draft-ietf-hip-rfc5205-bis-07.txt 2015-06-10 19:15:03.835028445 -0700 @@ -1,19 +1,19 @@ Network Working Group J. Laganier Internet-Draft Luminate Wireless, Inc. -Obsoletes: 5205 (if approved) January 16, 2015 +Obsoletes: 5205 (if approved) June 10, 2015 Intended status: Standards Track -Expires: July 20, 2015 +Expires: December 12, 2015 Host Identity Protocol (HIP) Domain Name System (DNS) Extension - draft-ietf-hip-rfc5205-bis-06 + draft-ietf-hip-rfc5205-bis-07 Abstract This document specifies a new resource record (RR) for the Domain 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 Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). This document obsoletes RFC5205. @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -48,45 +48,46 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 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 4. Overview of Using the DNS with HIP . . . . . . . . . . . . . 7 4.1. Storing HI, HIT, and RVS in the DNS . . . . . . . . . . . 7 4.2. Initiating Connections Based on DNS Names . . . . . . . . 8 - 5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 8 - 5.1. HIT Length Format . . . . . . . . . . . . . . . . . . . . 9 - 5.2. PK Algorithm Format . . . . . . . . . . . . . . . . . . . 9 - 5.3. PK Length Format . . . . . . . . . . . . . . . . . . . . 9 + 5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 9 + 5.1. HIT Length Format . . . . . . . . . . . . . . . . . . . . 10 + 5.2. PK Algorithm Format . . . . . . . . . . . . . . . . . . . 10 + 5.3. PK Length Format . . . . . . . . . . . . . . . . . . . . 10 5.4. HIT Format . . . . . . . . . . . . . . . . . . . . . . . 10 5.5. Public Key Format . . . . . . . . . . . . . . . . . . . . 10 5.6. Rendezvous Servers Format . . . . . . . . . . . . . . . . 10 - 6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . 10 - 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . 11 + 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 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.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative references . . . . . . . . . . . . . . . . . . 14 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 This document specifies a new resource record (RR) for the Domain 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 to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its HI), and the Domain Names of its rendezvous servers (RVSs) [I-D.ietf-hip-rfc5204-bis]. @@ -197,21 +198,21 @@ plain IP, it would send out more queries for A and AAAA types at the Responder's FQDN. Depending on the combinations of answers, the situations described in Section 3.1 and Section 3.2 can occur. 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 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 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 (HI-R) and Host Identity Tag (HIT-R) in a HIP resource record. An Initiator willing to associate with a node would typically issue the following queries: o QNAME=www.example.com, QTYPE=HIP @@ -340,35 +341,51 @@ equivalent situation occurs if no rendezvous server is present in the HIP resource record stored at that owner name. Such situations occur in two cases: 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 rendezvous server rather than its own one. 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) - 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 itself. An RVS receiving such an I1 would then relay it to the appropriate Responder (the owner of the I1 receiver HIT). The Responder will then complete the exchange with the Initiator, typically without ongoing help from the RVS. 4.2. Initiating Connections Based on DNS Names On a HIP node, a Host Identity Protocol exchange SHOULD be initiated whenever a ULP attempts to communicate with an entity and the DNS 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 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 rendezvous server(s). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HIT length | PK algorithm | PK length | @@ -587,31 +604,25 @@ based solely on a HIT retrieved from the DNS, but SHOULD rather use HI-based authentication. 8.3. DNSSEC In the absence of DNSSEC, the HIP RR is subject to the threats described in RFC 3833 [RFC3833]. 9. IANA Considerations - IANA has allocated one new RR type code (55) for the HIP RR from the - standard RR type space. - - 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 + IANA is requested to replace references to [RFC5205] by references to + this document in the the DNS RR type code registry. - 1 is DSA - 2 is RSA + IANA is requested to allocate the following algorithm type in the + IPSECKEY RR [RFC4025] registry: [IANA-TBD] is ECDSA 10. Contributors Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an earlier, experimental version of this specification [RFC5205]. 11. Acknowledgments @@ -700,18 +711,24 @@ [RFC5206] Henderson, T., Ed., "End-Host Mobility 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. o Extended DNS HIP RR to support for Host Identities based on 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 Julien Laganier Luminate Wireless, Inc. Cupertino, CA USA EMail: julien.ietf@gmail.com