Embedding Host Identity Tags Data in DNSHelsinki Institute for Information Technology HIITPO Box 9800TKKFIN-02015Finlandoleg.ponomarev@hiit.fiHelsinki Institute for Information Technology HIITPO Box 9800TKKFIN-02015Finlandgurtov@cs.helsinki.fi
Host Identity Protocol
Host Identity ProtocolThis document proposes conventions to access and manage
Host Identity Tag (HIT) mappings using the Domain Name System (DNS)
interface.One of the approaches to use legacy applications with Host Identity Protocol 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) .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.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.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. For example, the domain name corresponding to the
HITwould beThe 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 recordsThe PTR resource record types MAY be used to specify name of the host
using the Host Identity.The CNAME resource record types MAY be used to specify another domain
to lookup the locators of the system.The system MAY send DNS UPDATE 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.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.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 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.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 redundancyThe delegation of domain for reverse mapping is unlikely in this case
and would probably be blackholed similar to reverse subdomains for
private-use netblocks 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:The information about frequently accessed static hosts may be
available already at the first level.Such mapping does not have to be global. If the host has a domain
name with HIP and A/AAAA records, for exampleand 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):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.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: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.SHA1 is used now as a hash function to get HITs, but the complexity
of an existing 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.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.The authors would like to thank Tom Henderson and Miika Komu, who
provided comments and helped to improve this document.AS112 Nameserver OperationsAfilias Canada Corp.National Research Council of CanadaBIND 9 performance while serving large zones under updateISCNew Cryptanalytic Results Against SHA-1