Host Identity Protocol (HIP) Domain Name System (DNS) Extension
obsoletes
- rfc-5205 — Host Identity Protocol (HIP) Domain Name System (DNS) Extensions
Extracted elements (27)
The DNS is used for name-to-HI translation because most applications already rely on DNS for name-to-IP translation prior to communication. Defining a HIP RR allows the resolver to additionally perform name-to-HI lookup and construct the HI-to-IP mapping internal to the HIP layer, without disrupting existing ULPs.
The HIT included in the HIP RR is intended only as an optimization (e.g., table lookup), while the HIT used in the actual HIP exchange must always be freshly computed from the HI. This prevents reliance on potentially stale or colliding HIT values stored in DNS.
The Rendezvous Server field may include the owner name itself, or be absent; both are semantically equivalent. This handles both the mobile host case (A/AAAA RRs point to the RVS) and the stationary host case (host acts as its own RVS).
The HIP RR presentation format uses whitespace as a delimiter between the Public Key and Rendezvous Server fields, and between multiple RVS domain names; this whitespace is NOT part of the wire format and must not be included when encoding the RR on the wire.
The PK algorithm field reuses values defined for the IPSECKEY RR Algorithm Type (RFC 4025): DSA (1) and RSA (2) key formats also follow IPSECKEY RR definitions. This document adds ECDSA (3) with a format based on the DNSKEY RR RDATA for ECDSA per RFC 6605.
A HIP end-node implementation SHOULD NOT authenticate its HIP peers based solely on a HIT retrieved from the DNS, but rather SHOULD use HI-based authentication, due to the potential for hash collision attacks.
A HIP exchange SHOULD be initiated whenever a ULP attempts to communicate with an entity and the DNS lookup returns HIP RRs.
A HIP node SHOULD obtain HIP RRs from a trusted party through a secure channel ensuring data integrity and authenticity. DNSSEC (RFC 4033, 4034, 4035) provides such a secure channel.
If a HIP type query is answered with RCODE=3 (Name Error), the Responder's information is not present in the DNS, and further queries for the same owner name SHOULD NOT be made.
Rendezvous Server domain names in the HIP RR wire format MUST NOT be compressed.
The RRSIG of the HIP RRSet MUST NOT be misinterpreted as a certificate binding the HI and/or the HIT to the owner name. DNSSEC only provides data integrity and authenticity between the DNS server and the HIP node, not zone publisher trustworthiness.
Upon return of a HIP RR, a host MUST always calculate the HI-derivative HIT as specified in Section 3 of RFC 7401. The HIT included in the HIP RR SHOULD only be used as an optimization (e.g., table lookup), not as the authoritative HIT.
When multiple HIP RRs are present at the same owner name, a host MUST check that the RVS used is associated with the HI being used.
When the number of seconds that have passed since a HIP RR was retrieved exceeds the record's TTL, the record MUST be considered no longer valid and deleted. If the record is needed to initiate communication, a new query MUST be made to retrieve a fresh copy.
The HIP DNS Resource Record (RR type 55) allows a HIP node to publish its Host Identity (HI), Host Identity Tag (HIT), and optional Rendezvous Server (RVS) domain names in the DNS. It is class independent.
The HIT is stored as a binary value in network byte order. It is a truncated hash of the Host Identity (HI) public key.
The HIT Length field is an 8-bit unsigned integer indicating the length in bytes of the HIT field.
The PK Algorithm field is an 8-bit unsigned integer indicating the cryptographic algorithm and implied Public Key format. It reuses the Algorithm Type values defined for the IPSECKEY RR (RFC 4025): 1=DSA, 2=RSA, 3=ECDSA.
The PK Length field is a 16-bit unsigned integer in network byte order indicating the length in bytes of the Public Key field.
The Rendezvous Servers field contains one or more variable-length wire-encoded domain names concatenated per RFC 1035 Section 3.3, using zero-length labels as separators. Domain names MUST NOT be compressed. RVSs are listed in order of preference within a single RR; preference ordering MUST NOT be inferred across multiple RRs.
IANA assigned Algorithm Type value 3 in the 'Algorithm Type Field' subregistry under 'IPSECKEY Resource Record Parameters' for ECDSA: 'An ECDSA key is present, in the format defined in RFC 6605'.
The 'Resource Record (RR) TYPEs' subregistry under 'Domain Name System (DNS) Parameters' contains HIP at value 55. References to RFC 5205 have been updated to reference this document (RFC 8005).
An attacker able to tamper with an insecure HIP RR (e.g., via DNS spoofing) can mount man-in-the-middle attacks on the cryptographic core of the HIP exchange by substituting the Responder's HI, and can redirect I1 packets to an attacker-controlled IP by altering the RVS field.
In the absence of DNSSEC, the HIP RR is subject to the DNS threat taxonomy described in RFC 3833, including cache poisoning, birthday attacks, and query prediction attacks.
Secure hashes used to derive HITs from HIs (e.g., SHA-1) can become insecure over time due to discovered exploits against collision resistance. This motivates using HI-based rather than HIT-based peer authentication.
The ECDSA Public Key format is defined as the algorithm-specific portion of the DNSKEY RR RDATA for ECDSA (RFC 6605): all DNSKEY RR data after the first four octets, corresponding to the portion a DNSSEC algorithm document must specify.
The HIP RR RDATA consists of: HIT length (8-bit), PK algorithm (8-bit), PK length (16-bit, network byte order), HIT (variable, binary), Public Key (variable), and optionally one or more Rendezvous Server domain names (wire-encoded, variable). The HIT length, PK algorithm, PK length, HIT, and Public Key fields are REQUIRED; the Rendezvous Server field is OPTIONAL.