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.

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
2.  Domain names for HIT mappings
    2.1.  Preconfigured Domain
    2.2.  Listing IP Addresses of the System
    2.3.  Listing host names
    2.4.  Link to another domain
    2.5.  Managing the Records
3.  Usage scenarios
    3.1.  Initial deployment
    3.2.  Parallel services
    3.3.  Two-level mapping
    3.4.  Local mapping
    3.5.  Link to mapping service
4.  Security Considerations
5.  IANA Considerations
6.  Acknowledgments
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Authors' Addresses

1.  Introduction

One of the approaches to use legacy applications[RFC5338] (Henderson, T., Nikander, P., and M. Komu, “Using the Host Identity Protocol with Legacy Applications,” September 2008.) with Host Identity Protocol[RFC4423] (Moskowitz, R. and P. Nikander, “Host Identity Protocol (HIP) Architecture,” May 2006.) 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] (Ahrenholz, J., “HIP DHT Interface,” October 2008.).

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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] (Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, “DNS Extensions to Support IP Version 6,” October 2003.). 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.

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] (Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, “Dynamic Updates in the Domain Name System (DNS UPDATE),” April 1997.) 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.

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] (Reid, B., “BIND 9 performance while serving large zones under update,” February 2008.) 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 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] (Abley, J. and W. Maton, “AS112 Nameserver Operations,” November 2008.)

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:

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 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.

4.  Security Considerations

SHA1 is used now as a hash function to get HITs, but the complexity of an existing attack[SHA1‑attack] (Schneier, B., “New Cryptanalytic Results Against SHA-1,” August 2005.) 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.

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.

6.  Acknowledgments

The authors would like to thank Tom Henderson and Miika Komu, who provided comments and helped to improve this document.

7.  References

7.1. Normative References

7.2. Informative References

Authors' Addresses