--- 1/draft-ietf-hip-dns-04.txt 2006-02-17 22:12:22.000000000 +0100 +++ 2/draft-ietf-hip-dns-05.txt 2006-02-17 22:12:22.000000000 +0100 @@ -1,19 +1,19 @@ Network Working Group P. Nikander Internet-Draft Ericsson Research Nomadic Lab -Expires: June 19, 2006 J. Laganier +Expires: August 20, 2006 J. Laganier DoCoMo Euro-Labs - December 16, 2005 + February 16, 2006 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions - draft-ietf-hip-dns-04 + draft-ietf-hip-dns-05 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,66 +24,65 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 19, 2006. + This Internet-Draft will expire on August 20, 2006. Copyright Notice - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). 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 (RVS.) Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Simple static singly homed end-host . . . . . . . . . . . 6 3.2. Mobile end-host . . . . . . . . . . . . . . . . . . . . . 7 - 3.3. Mixed Scenario . . . . . . . . . . . . . . . . . . . . . . 8 - 4. Overview of using the DNS with HIP . . . . . . . . . . . . . . 11 - 4.1. Storing HI, HIT and RVS in DNS . . . . . . . . . . . . . . 11 - 4.2. Initiating connections based on DNS names . . . . . . . . 11 - 5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 12 - 5.1. HIT length format . . . . . . . . . . . . . . . . . . . . 12 - 5.2. PK algorithm format . . . . . . . . . . . . . . . . . . . 12 - 5.3. PK length format . . . . . . . . . . . . . . . . . . . . . 13 - 5.4. HIT format . . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.5. Public key format . . . . . . . . . . . . . . . . . . . . 13 - 5.6. Rendezvous servers format . . . . . . . . . . . . . . . . 13 - 6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . . 14 - 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 8.1. Attacker tampering with an insecure HIP RR . . . . . . . . 16 - 8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . . 17 - 8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 11.1. Normative references . . . . . . . . . . . . . . . . . . . 20 - 11.2. Informative references . . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 - Intellectual Property and Copyright Statements . . . . . . . . . . 23 + 4. Overview of using the DNS with HIP . . . . . . . . . . . . . . 9 + 4.1. Storing HI, HIT and RVS in DNS . . . . . . . . . . . . . . 9 + 4.2. Initiating connections based on DNS names . . . . . . . . 9 + 5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 10 + 5.1. HIT length format . . . . . . . . . . . . . . . . . . . . 10 + 5.2. PK algorithm format . . . . . . . . . . . . . . . . . . . 10 + 5.3. PK length format . . . . . . . . . . . . . . . . . . . . . 11 + 5.4. HIT format . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.5. Public key format . . . . . . . . . . . . . . . . . . . . 11 + 5.6. Rendezvous servers format . . . . . . . . . . . . . . . . 11 + 6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . . 12 + 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 8.1. Attacker tampering with an insecure HIP RR . . . . . . . . 14 + 8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . . 15 + 8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 11.1. Normative references . . . . . . . . . . . . . . . . . . . 18 + 11.2. Informative references . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 + Intellectual Property and Copyright Statements . . . . . . . . . . 21 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-base]. 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 (RVS.) [I-D.ietf-hip-rvs] @@ -160,81 +159,82 @@ address(es) in the DNS. For solving this problem, the HIP architecture introduces rendezvous servers (RVS.) A HIP host uses a rendezvous server as a rendezvous point, to maintain reachability with possible HIP initiators. Such a HIP node would publish in the DNS its RVS 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 will perform a number of DNS lookups. Depending on the type of the implementation, the order in which those lookups will be issued may - vary. For instance, implementations using IP address in APIs may - typically first query for A and/or AAAA records at the responder - FQDN, while those using HIT in APIS may typically first query for HIP - RRs. + vary. For instance, implementations using HIT in APIS may typically + 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 + AAAA resource records. - In the following we assume that the initiator first queries for A - and/or AAAA records at the responder FQDN. + In the following we assume that the initiator first queries for HIP + resource records at the responder FQDN. - If the query for the A and/or AAAA was responded to with a DNS answer - with RCODE=3 (Name Error), then the responder's information is not - present in the DNS and further queries SHOULD NOT be made. + If the query for the HIP type was responded to with a DNS answer with + RCODE=3 (Name Error), then the responder's information is not present + in the DNS and further queries SHOULD NOT be made. - In case the query for the address records returned a DNS answer with + In case the query for the HIP records returned a DNS answer with RCODE=0 (No Error), then the initiator sends out one more query for - for the HIP type at the responder's FQDN. + for A and AAAA types at the responder's FQDN. Depending on the combinations of answer the situations described in - Section 3.1, Section 3.2 and Section 3.3 can occur. + Section 3.1 and Section 3.2 can occur. Note that storing HIP RR information in the DNS at a FQDN which 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 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: - QNAME=www.example.com, QTYPE=A + QNAME=www.example.com, QTYPE=HIP (QCLASS=IN is assumed and omitted from the examples) - Which returns a DNS packet with RCODE=0 and one or more A RRs A with - the address of the responder (e.g. IP-R) in the answer section. - - QNAME=www.example.com, QTYPE=HIP - Which returns a DNS packet with RCODE=0 and one or more HIP RRs with the HIT and HI (e.g. HIT-R and HI-R) of the responder in the answer section, but no RVS. + QNAME=www.example.com, QTYPE=A + + Which returns a DNS packet with RCODE=0 and one or more A or AAAA RRs + containing IP address(es) of the responder (e.g. IP-R) in the answer + section. + Caption: In the remainder of this document, for the sake of keeping diagrams simple and concise, several DNS queries and answers are represented as one single transaction, while in fact there are several queries and answers flowing back and forth, as described in the textual examples. - [A? HIP? ] + [HIP? A? ] [www.example.com] +-----+ +-------------------------------->| | | | DNS | | +-------------------------------| | - | | [A? HIP? ] +-----+ + | | [HIP? A? ] +-----+ | | [www.example.com] - | | [A IP-R ] | | [HIP HIT-R HI-R ] + | | [A IP-R ] | v +-----+ +-----+ | |--------------I1------------->| | | I |<-------------R1--------------| R | | |--------------I2------------->| | | |<-------------R2--------------| | +-----+ +-----+ The initiator would then send an I1 to the responder's IP addresses (IP-R.) @@ -244,41 +244,41 @@ A mobile HIP node (R) wishing to be reachable by reference to its FQDN (www.example.com) would store in the DNS, possibly in addition to its IP address(es) (IP-R), its HI (HI-R), HIT (HIT-R) and the domain name(s) of its rendezvous server(s) (rvs.example.com) in HIP resource record(s). The mobile HIP node also needs to notify its rendezvous servers of any change in its set of IP address(es). An initiator willing to associate with such mobile node would typically issue the following queries: - QNAME=www.example.com, QTYPE=A - - Which returns a DNS packet with RCODE=0 and an empty answer section. - QNAME=www.example.com, QTYPE=HIP Which returns a DNS packet with RCODE=0 and one or more HIP RRs with the HIT, HI and RVS domain name(s) (e.g. HIT-R, HI-R, and rvs.example.com) of the responder in the answer section. QNAME=rvs.example.com, QTYPE=A - [A? HIP? ] + Which returns a DNS packet with RCODE=0 and one or more A or AAAA RRs + containing IP address(es) of the responder's RVS (e.g. IP-RVS) in + the answer section. + + [HIP? ] [www.example.com] [A? ] - [RVS.example.com] +-----+ + [rvs.example.com] +-----+ +----------------------------------------->| | | | DNS | | +----------------------------------------| | - | | [A? HIP? ] +-----+ + | | [HIP? ] +-----+ | | [www.example.com ] | | [HIP HIT-R HI-R rvs.example.com] | | | | [A? ] | | [rvs.example.com] | | [A IP-RVS ] | | | | +-----+ | | +------I1----->| RVS |-----I1------+ | | | +-----+ | @@ -288,79 +288,20 @@ +-----+ +-----+ | |<---------------R1------------| | | I |----------------I2----------->| R | | |<---------------R2------------| | +-----+ +-----+ The initiator would then send an I1 to the RVS IP address (IP-RVS.) Following, the RVS will relay the I1 up to the mobile node's IP address (IP-R), which will complete the HIP exchange. -3.3. Mixed Scenario - - A HIP node might be configured with more than one IP address (multi- - homed), or rendezvous server (multi-reachable.) In these cases, it - is possible that the DNS returns multiple A or AAAA RRs, as well as - HIP RRs containing one or multiple rendezvous servers. In addition - to its set of IP address(es) (IP-R1, IP-R2), a multi-homed end-host - would store in the DNS its HI (HI-R), HIT (HIT-R) and domain name(s) - of its RVS(s) (rvs.example.com) in HIP RRs. - - An initiator willing to associate with such mobile node would - typically issue the following queries: - - QNAME=www.example.com, QTYPE=A - - Which returns a DNS packet with RCODE=0 and one or more A or AAAA RRs - containing IP address(es) (e.g. IP-R1 and IP-R2) in the answer - section. - - QNAME=www.example.com, QTYPE=HIP - - Which returns a DNS packet with RCODE=0 and one or more HIP RRs with - the HIT, HI and RVS domain name(s) (e.g. HIT-R, HI-R, and - rvs.example.com) of the responder in the answer section. - - QNAME=rvs.example.com, QTYPE=A - - [A? HIP? ] - [www.example.com] - - [A? ] - [RVS.example.com] +-----+ - +----------------------------------------->| | - | | DNS | - | +----------------------------------------| | - | | [A? HIP? ] +-----+ - | | [www.example.com ] - | | [A IP-R ] - | | [HIP HIT-R HI-R rvs.example.com] - | | - | | [A? ] - | | [rvs.example.com] - | | [A IP-RVS ] - | | - | | +-----+ - | | +------I1----->| RVS |-----I1------+ - | | | +-----+ | - | | | | - | | | | - | v | v - +-----+ +-----+ - | |----------------I1----------->| | - | |<---------------R1------------| | - | I |----------------I2----------->| R | - | |<---------------R2------------| | - +-----+ +-----+ - The initiator would then typically send the same I1 to both the RVS - and the responder's IP addresses (IP-RVS and IP-R.) - 4. Overview of using the DNS with HIP 4.1. Storing HI, HIT and RVS in DNS Any conforming implementation may store a Host Identity (HI) and its associated Host Identity Tag (HIT) in a DNS HIP RDATA format. If a particular form of an HI does not already have a specified RDATA format, a new RDATA-like format SHOULD be defined for the HI. HI and HIT are defined in Section 3 of [I-D.ietf-hip-base]. @@ -368,20 +309,35 @@ derivative HIT to be used in the HIP exchange, as specified in Section 3 of the HIP base specification [I-D.ietf-hip-base], while the HIT possibly embedded along SHOULD only be used as an optimization (e.g. table lookup.) The HIP resource record may also contains one or more domain name(s) of rendezvous server(s) towards which HIP I1 packets might be sent to trigger the establishment of an association with the entity named by this resource record [I-D.ietf-hip-rvs]. + The rendezvous server field of the HIP resource record stored at a + given domain name MAY include the domain name itself. A semantically + equivalent situation occurs if no rendezvous server is stored in the + HIP resource record of that domain. Such situations occurs in two + cases: + + o The host is mobile, and the A and/or AAAA resource record(s) + stored at its domain name contains the IP address(es) of its + rendezvous server rather than its own one. + + o The host is stationary, and can be reached directly at IP + address(es) contained in A and/or AAAA resource record(s) stored + at its domain name. This a degenerated 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 an Upper Layer Protocol attempt to communicate with an entity and the DNS lookup returns HIP resource records. @@ -754,18 +710,18 @@ This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement - Copyright (C) The Internet Society (2005). This document is subject + Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.