Host Identity Protocol O. Ponomarev Internet-Draft A. Gurtov Intended status: Experimental Helsinki Institute for Information Expires: September 10, 2009 Technology HIIT March 9, 2009 Embedding Host Identity Tags Data in DNS draft-ponomarev-hip-hit2ip-03 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." 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 September 10, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Ponomarev & Gurtov Expires September 10, 2009 [Page 1] Internet-Draft HIT-TO-IP March 2009 Abstract This document proposes conventions to access and manage Host Identity Tag (HIT) mappings using the Domain Name System (DNS) interface. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Domain names for HIT mappings . . . . . . . . . . . . . . . . 4 2.1. Preconfigured Domain . . . . . . . . . . . . . . . . . . . 4 2.2. Listing IP Addresses of the System . . . . . . . . . . . . 4 2.3. Listing host names . . . . . . . . . . . . . . . . . . . . 4 2.4. Link to another domain . . . . . . . . . . . . . . . . . . 5 2.5. Managing the Records . . . . . . . . . . . . . . . . . . . 5 3. Usage scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Initial deployment . . . . . . . . . . . . . . . . . . . . 6 3.2. Parallel services . . . . . . . . . . . . . . . . . . . . 6 3.3. Two-level mapping . . . . . . . . . . . . . . . . . . . . 7 3.4. Local mapping . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Link to mapping service . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Ponomarev & Gurtov Expires September 10, 2009 [Page 2] Internet-Draft HIT-TO-IP March 2009 1. Introduction One of the approaches to use legacy applications[RFC5338] with Host Identity Protocol[RFC4423] is to use HIT as IPv6 address. The application may receive them from the nameserver, store internally and connect directly to a HIT. The HIP software would receive packet with HIT as a destination IPv6 address without any additional information about the current locator and therefore some HIT resolution service is needed in this case. This document suggests the DNS as a protocol to access such mapping databases in addition to a local list of Host Identities and Distributed Hash Tables (DHT) [I-D.ahrenholz-hiprg-dht]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119[RFC2119]. Ponomarev & Gurtov Expires September 10, 2009 [Page 3] Internet-Draft HIT-TO-IP March 2009 2. Domain names for HIT mappings Domain Name System is well-known to systems administrators and there is much experience with operations under high load. It also allows dynamic modifications and has low overhead when compared to many other protocols. It is used now, for example, to get IP address reputations from various blacklists. 2.1. Preconfigured Domain The systems using this method MUST have the same domain pre- configured, for example hit-to-ip.example.net. If there are multiple parallel services with their own domains, the systems MUST have at least one of them in common to interoperate. A HIT is represented as a sequence of nibbles separated by dots and followed by the suffix similarly to IPv6 addresses in ip6.arpa[RFC3596]. For example, the domain name corresponding to the HIT 2001:10:1234:5678:9abc:def0:1234:5678 would be 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. hit-to-ip.example.net 2.2. Listing IP Addresses of the System The A/AAAA resource record types MAY be used to specify the IP/IPv6 addresses of the system. There MAY be multiple locators listed for a HIT. For example, the system with IP address 192.0.2.1 and IPv6 address 2001:DB8::1 would have the following records 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. hit-to-ip.example.net. 1 IN A 192.0.2.1 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. hit-to-ip.example.net. 1 IN AAAA 2001:DB8::1 2.3. Listing host names The PTR resource record types MAY be used to specify name of the host using the Host Identity. Ponomarev & Gurtov Expires September 10, 2009 [Page 4] Internet-Draft HIT-TO-IP March 2009 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. hit-to-ip.example.net. 86400 IN PTR alpha.example.com. 2.4. Link to another domain The CNAME resource record types MAY be used to specify another domain to lookup the locators of the system. 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. hit-to-ip.example.net. 86400 IN CNAME 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5. 4.3.2.1.0.1.0.0.1.0.0.2.hit-to-ip.domain.example. 2.5. Managing the Records The system MAY send DNS UPDATE[RFC2136] to the server provided by SOA MNAME field of the domain. The system MAY add or delete A,AAAA,PTR,CNAME records for its own HIT representation. The update MUST then originate from the corresponding HIT. If there are multiple identities they should be modified separately. The domain provided in SOA MNAME field of the preconfigured domain MUST have Host Identity of the server stored in DNS, the IP addresses MUST be listed in that domain using the suggested method and the server MUST accept DNS UPDATE messages, which add or delete A,AAAA,PTR,CNAME records for the HIT representation of the client after successful HIP base exchange. The HIP base exchange serves to authenticate the origin of the DNS UPDATE and server MUST refuse to perform the changes if the update is not originating from the host identity whose data is being updated. Ponomarev & Gurtov Expires September 10, 2009 [Page 5] Internet-Draft HIT-TO-IP March 2009 3. Usage scenarios The DNS selected as an interface should help in the deployment. There is vast number of resursive DNS resolvers available to the clients, they can cache mapping information, for example. This section contains ideas about different designs of the mapping service. 3.1. Initial deployment Such global mapping service would be useful for the Host Identities that are not published for any domain name. It can be started up using the conventional DNS software with minor changes to authenticate DNS updates with HIP. There is hit-to-ip.net zone available for the experiments at the moment. According to the measurements[ISC-TN-2008-1] BIND 9 is able to send 60,361 replies/ second under update at 256 updates/sec over IXFR. The performance of DDNS updates was only 93.46 updates/second as they are committed to nonvolatile storage before the response is returned. The version of BIND compiled without the file-system commits performed 471.70 updates/second. The performance of HIP implementations also limits the capacity, but about active 100,000 users may be served assuming 1 hour average update interval, if the peak performance is 100 updates/ second. Number of mappings that fits into the memory of a modern server has to be studied. The TTL of the records is selected by the clients. If a Host Identity is used by a server with static IP addresses, its mappings may have long TTLs as any changes are scheduled in advance. This would allow the recursive resolvers to cache records of the frequently accessed static servers. Delegation of 1.0.0.1.0.0.2.ip6.arpa would allow reverse resolution of HIT to a host name by any system without any changes. The host name does not change often and such mapping may be updated only when needed. Although the service may be started with existing DNS software, it is not optimal for such a usage pattern and another database engine allowing higher update rate is needed. 3.2. Parallel services Although it is not desirable, there may be multiple independent mapping services. I.e. the host updates its IP addresses only in hit-to-ip.domain1.example, but has to look for IP addresses of an unknown host in hit-to-ip.domain1.example, hit-to-ip.domain2.example and hit-to-ip.domain3.example. This causes extra traffic due to Ponomarev & Gurtov Expires September 10, 2009 [Page 6] Internet-Draft HIT-TO-IP March 2009 multiple lookups. Another possibility is that the host updates its IP addresses in hit- to-ip.domain1.example, hit-to-ip.domain2.example and hit-to- ip.domain3.example, but chose only hit-to-ip.domain1.example to lookup unknown hosts. This would cause growth of all three databases with every new user and extra traffic due to multiple updates, but provides redundancy The delegation of domain for reverse mapping is unlikely in this case and would probably be blackholed similar to reverse subdomains for private-use netblocks [I-D.ietf-dnsop-as112-ops] 3.3. Two-level mapping The flat identifiers do not have administrative division as in usual domain names and a single organization should serve all the identifiers. Therefore it is desirable to reduce its workload at the same time TTL of the records cannot be long to allow dynamic changes. Two-level design might help to solve this contradiction. The first level would contain only links (CNAME) to different second level mapping providers. Such information does not change often and can have long TTL. Furthermore in this case, it would be enough to store in memory only HIT and an index of the second level provider both in binary format. The second level mapping would contain dynamic information about the current IP addresses. For example, there may be the following records in the DNS: Ponomarev & Gurtov Expires September 10, 2009 [Page 7] Internet-Draft HIT-TO-IP March 2009 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. hit-to-ip.arpa. 86400 IN CNAME 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5. 4.3.2.1.0.1.0.0.1.0.0.2.hit-to-ip.domain.example. 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. ip6.arpa. 86400 IN CNAME 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5. 4.3.2.1.0.1.0.0.1.0.0.2.hit-to-host.domain.example. 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. hit-to-ip.domain.example. 1 IN A 192.0.2.1 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. hit-to-ip.domain.example. 1 IN AAAA 2001:DB8::1 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. hit-to-host.domain.example. 86400 IN PTR alpha.example.com. The information about frequently accessed static hosts may be available already at the first level. 3.4. Local mapping Such mapping does not have to be global. If the host has a domain name with HIP and A/AAAA records, for example alpha.example.com. 3600 IN HIP {2001:10:1234:5678:9abc:def0:1234:5678} 3600 IN A 192.0.2.1 3600 IN AAAA 2001:DB8::1 and a legacy application sends AAAA? query to its recursive nameserver, the nameserver may reply with 2001:10:1234:5678:9abc: def0:1234:5678 in AAAA data and add the following domain name (unless it already exists): 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. hit-to-ip.domain.example. 86400 IN CNAME alpha.example.com. The application would send packets to 2001:10:1234:5678:9abc:def0: 1234:5678 and HIP software would be able to retrieve its current location from the local hit-to-ip mapping. The nameserver may remove the mapping sometimes, but it might be needed for a long time if the Ponomarev & Gurtov Expires September 10, 2009 [Page 8] Internet-Draft HIT-TO-IP March 2009 application stores 2001:10:1234:5678:9abc:def0:1234:5678 internally. The same technique may be used with Local Scope Identifiers for IPv4 legacy applications. 3.5. Link to mapping service Some users can change the records for their domain manually, but do not have DDNS updates. Then it would be usefull to publish data (including full Host Identity) in the mapping service and put CNAME for the domain name: alpha.example.com. CNAME 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9. 8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2.hit-to-ip.domain.example. 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. hit-to-ip.domain.example. 86400 IN HIP {2001:10:1234:5678:9abc:def0:1234:5678} 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. hit-to-ip.domain.example. 1 IN A 192.0.2.1 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. hit-to-ip.domain.example. 1 IN AAAA 2001:DB8::1 In this case, a legacy system would resolve the hostname to its IP addresses and would reach its current location, a HIP hosts would start HIP session. Any other dynamic DNS service may be used, if it allows HIP resource records. Ponomarev & Gurtov Expires September 10, 2009 [Page 9] Internet-Draft HIT-TO-IP March 2009 4. Security Considerations SHA1 is used now as a hash function to get HITs, but the complexity of an existing attack[SHA1-attack] is only 2**63. Since only HIT, but not complete HI is used for lookups, SHA1 should be phased out, for example, in favor of the SHA-2 variants. The actions, when multiple hosts share the same identity and start to constantly update their mappings, should be discussed. Ponomarev & Gurtov Expires September 10, 2009 [Page 10] Internet-Draft HIT-TO-IP March 2009 5. IANA Considerations This draft would require that the IANA delegates 1.0.0.1.0.0.2.IP6.ARPA subdomain and HIT-TO-IP.ARPA for the Host Identity Protocol usage. Ponomarev & Gurtov Expires September 10, 2009 [Page 11] Internet-Draft HIT-TO-IP March 2009 6. Acknowledgments The authors would like to thank Tom Henderson and Miika Komu, who provided comments and helped to improve this document. Ponomarev & Gurtov Expires September 10, 2009 [Page 12] Internet-Draft HIT-TO-IP March 2009 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host Identity Protocol with Legacy Applications", RFC 5338, September 2008. 7.2. Informative References [I-D.ahrenholz-hiprg-dht] Ahrenholz, J., "HIP DHT Interface", draft-ahrenholz-hiprg-dht-03 (work in progress), October 2008. [I-D.ietf-dnsop-as112-ops] Abley, J. and W. Maton, "AS112 Nameserver Operations", draft-ietf-dnsop-as112-ops-01 (work in progress), November 2008. [ISC-TN-2008-1] Reid, B., "BIND 9 performance while serving large zones under update", February 2008, . [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. [SHA1-attack] Schneier, B., "New Cryptanalytic Results Against SHA-1", August 2005, . Ponomarev & Gurtov Expires September 10, 2009 [Page 13] Internet-Draft HIT-TO-IP March 2009 Authors' Addresses Oleg Ponomarev Helsinki Institute for Information Technology HIIT PO Box 9800 TKK FIN-02015 Finland Email: oleg.ponomarev@hiit.fi Andrei Gurtov Helsinki Institute for Information Technology HIIT PO Box 9800 TKK FIN-02015 Finland Email: gurtov@cs.helsinki.fi Ponomarev & Gurtov Expires September 10, 2009 [Page 14]