Host Identity Protocol O. Ponomarev
Internet-Draft A. Gurtov
Intended status: Experimental Helsinki Institute for Information
Expires: September 7, 2009 Technology HIIT
March 6, 2009
Embedding Host Identity Tags Data in DNS
draft-ponomarev-hip-hit2ip-01
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 7, 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 7, 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
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Ponomarev & Gurtov Expires September 7, 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 7, 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 7, 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 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 7, 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 amount of resursive DNS resolvers available to the
clients, they can cache mapping information, for example. This
section contains ideas about three different designs of the mapping
service.
3.1. Initial deployment
Such mapping services can be started 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 experiments[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
multiple lookups.
Ponomarev & Gurtov Expires September 7, 2009 [Page 6]
Internet-Draft HIT-TO-IP March 2009
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:
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
Ponomarev & Gurtov Expires September 7, 2009 [Page 7]
Internet-Draft HIT-TO-IP March 2009
The information about frequently accessed static hosts may be
available already at the first level.
Ponomarev & Gurtov Expires September 7, 2009 [Page 8]
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 7, 2009 [Page 9]
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 7, 2009 [Page 10]
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 7, 2009 [Page 11]
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,
<http://new.isc.org/proj/dnsperf/ISC-TN-2008-1.html>.
[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, <http://www.schneier.com/blog/archives/2005/
08/new_cryptanalyt.html>.
Ponomarev & Gurtov Expires September 7, 2009 [Page 12]
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 7, 2009 [Page 13]