[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04
Host Identity Protocol O. Ponomarev
Internet-Draft A. Gurtov
Intended status: Experimental Helsinki Institute for Information
Expires: January 14, 2010 Technology HIIT
July 13, 2009
Embedding Host Identity Tags Data in DNS
draft-ponomarev-hip-hit2ip-04
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 January 14, 2010.
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 January 14, 2010 [Page 1]
Internet-Draft HIT-TO-IP July 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 Locators of the System in the Extended Format . . 4
2.4. Listing Host Names . . . . . . . . . . . . . . . . . . . . 5
2.5. Link to another domain . . . . . . . . . . . . . . . . . . 5
2.6. 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 January 14, 2010 [Page 2]
Internet-Draft HIT-TO-IP July 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 January 14, 2010 [Page 3]
Internet-Draft HIT-TO-IP July 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 Locators of the System in the Extended Format
All the available locators of various types MAY be listed in a signle
record using extended format of HIP RR as in
draft-ponomarev-hip-dns-locators [I-D.ponomarev-hip-dns-locators].
Ponomarev & Gurtov Expires January 14, 2010 [Page 4]
Internet-Draft HIT-TO-IP July 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.
1 IN HIP
{2001:10:1234:5678:9abc:def0:1234:5678}{}{192.0.2.1,2001:DB8::1}
2.4. 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.5. 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.6. 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 January 14, 2010 [Page 5]
Internet-Draft HIT-TO-IP July 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 January 14, 2010 [Page 6]
Internet-Draft HIT-TO-IP July 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 January 14, 2010 [Page 7]
Internet-Draft HIT-TO-IP July 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 January 14, 2010 [Page 8]
Internet-Draft HIT-TO-IP July 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 January 14, 2010 [Page 9]
Internet-Draft HIT-TO-IP July 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 January 14, 2010 [Page 10]
Internet-Draft HIT-TO-IP July 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 January 14, 2010 [Page 11]
Internet-Draft HIT-TO-IP July 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 January 14, 2010 [Page 12]
Internet-Draft HIT-TO-IP July 2009
7. References
7.1. Normative References
[I-D.ponomarev-hip-dns-locators]
Ponomarev, O., "Storing Host Locators in HIP Resource
Record", draft-ponomarev-hip-dns-locators-00 (work in
progress), July 2009.
[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 January 14, 2010 [Page 13]
Internet-Draft HIT-TO-IP July 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 January 14, 2010 [Page 14]
Html markup produced by rfcmarkup 1.111, available from
https://tools.ietf.org/tools/rfcmarkup/