One document matched: draft-ietf-hip-dns-08.xml
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY % RFC1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034" >
<!ENTITY % RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035" >
<!ENTITY % RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119" >
<!ENTITY % RFC2536 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2536" >
<!ENTITY % RFC3110 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3110" >
<!ENTITY % RFC3596 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3596" >
<!ENTITY % RFC3833 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3833" >
<!ENTITY % RFC4025 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4025" >
<!ENTITY % RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033" >
<!ENTITY % RFC4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034" >
<!ENTITY % RFC4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035" >
<!ENTITY % RFC4423 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4423" >
<!ENTITY % I-D.ietf-hip-base SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-base" >
<!ENTITY % I-D.ietf-hip-mm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-mm" >
<!ENTITY % I-D.ietf-hip-rvs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rvs" >
<!ENTITY % I-D.jokela-hip-esp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-esp" >
<!ENTITY % RFC4648 SYSTEM "reference.RFC.4648" >
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<rfc category="std" ipr="full3978" >
<front>
<title abbrev="HIP DNS Extensions">Host Identity Protocol (HIP) Domain Name System (DNS) Extensions</title>
<author initials="P." surname="Nikander"
fullname="Pekka Nikander">
<organization>Ericsson Research Nomadic Lab</organization>
<address>
<postal>
<street />
<city>JORVAS</city>
<code>FIN-02420</code>
<country>FINLAND</country>
</postal>
<phone>+358 9 299 1</phone>
<email>pekka.nikander@nomadiclab.com</email>
</address>
</author>
<author initials="J." surname="Laganier"
fullname="Julien Laganier">
<organization abbrev="DoCoMo Euro-Labs">
DoCoMo Communications Laboratories Europe GmbH
</organization>
<address> <postal>
<street> Landsberger Strasse 312
</street>
<city>Munich</city>
<code>80687</code>
<country>Germany</country>
</postal>
<phone>+49 89 56824 231</phone>
<email>julien.ietf@laposte.net</email>
<uri>http://www.docomolab-euro.com/</uri>
</address>
</author>
<date year="2006"/>
<area>Internet</area>
<keyword>I-D</keyword>
<keyword>Internet Draft</keyword>
<abstract>
<t>
This document specifies a new resource record (RR) for the
Domain Name System (DNS), and how to use it with the Host
Identity Protocol (HIP.) This RR allows a HIP node to store
in the DNS its Host Identity (HI, the public component of the
node public-private key pair), Host Identity Tag (HIT, a
truncated hash of its public key), and the Domain Names of its
rendezvous servers (RVS.)
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document specifies a new resource record (RR) for the
<xref target="RFC1034"> Domain Name System (DNS) </xref>, and
how to use it with the <xref target="I-D.ietf-hip-base">
Host Identity Protocol (HIP)</xref>. This RR allows a
HIP node to store in the DNS its Host Identity (HI, the public
component of the node public-private key pair), Host Identity
Tag (HIT, a truncated hash of its HI), and the Domain Names
of its <xref target="I-D.ietf-hip-rvs">rendezvous
servers (RVS.)</xref>
</t>
<!-- <t>
The current Internet architecture defines two global
namespaces: IP addresses and domain names. The Domain Name
System provides a two way lookup between these two
namespaces. The <xref target="I-D.ietf-hip-arch">HIP
architecture</xref> defines a new third namespace,
called the Host Identity Namespace. This namespace is
composed of Host Identifiers (HI) of HIP nodes. The Host
Identity Tag (HIT) is one representation of an HI. This
representation is obtained by taking the output of a secure
hash function applied to the HI, truncated to the IPv6
address size. HITs are intended to be used in the place of
IP addresses within most ULPs and applications.
</t>
<t>
The <xref target="I-D.ietf-hip-base">Host Identity
Protocol </xref> allows two HIP nodes to
establish a HIP Association.
A HIP association is bound to
the nodes HIs rather than to their IP address(es).
</t>
<t>
A HIP node establishes a HIP association by initiating a 4 way handshake
where two parties, the initiator and responder, exchange the I1,
I2, R1 and R2 HIP packets (see section 5.3 of <xref target="I-D.ietf-hip-base"/>)
</t>
<t>
<figure title="HIP Base Exchange" target="ex">
<artwork>
+-----+ +-----+
| |-------I1------>| |
| I |<------R1-------| R |
| |-------I2------>| |
| |<------R2-------| |
+-----+ +-----+
</artwork>
</figure>
</t>
<t>
Although a HIP node can initiate HIP communication
"opportunistically", i.e., without prior knowledge of its
peer's HI, doing so exposes both endpoints to Man-in-the-Middle
attacks on the HIP handshake and its cryptographic protocol.
Hence, there is a desire to gain knowledge of peers' HI before
applications and ULPs initiate communication. Because many
applications use the <xref target="RFC1034">Domain Name System</xref> to
name nodes, DNS
is a straightforward way
to provision nodes with the HIP information (i.e. HI, HIT and
possibly RVS) of nodes named in the DNS tree, without
introducing or relying on an additional piece of
infrastructure. Note that in the absence of <xref target="RFC2065">DNSSEC</xref>,
the DNS name resolution is vulnerable to a Man-in-the-Middle attack (See <xref target="sec-cons"/>),
and hence the HIP handshake is also vulnerable to a Man-in-the-Middle attack.
</t>
<t>
The proposed <xref target="I-D.ietf-hip-mm">HIP
multi-homing mechanisms</xref> allow a node to
dynamically change its set of underlying IP addresses
while maintaining IPsec SA and transport layer session
survivability. The <xref target="I-D.ietf-hip-rvs">HIP
rendezvous extensions</xref> proposal allows a
HIP node to maintain HIP reachability while it is
changing its current location (the node IP
address(es)). This rendezvous service is provided by a
third party, the node's rendezvous server (RVS).
</t>
<t>
<figure target="rvs" title="HIP Base Exchange Via a Rendezvous Server" >
<artwork>
+-----+
+--I1--->| RVS |---I1--+
| +-----+ |
| v
+-----+ +-----+
| |<------R1-------| |
| I |-------I2------>| R |
| |<------R2-------| |
+-----+ +-----+
</artwork>
</figure>
</t>
<t>
An initiator (I) willing to establish a HIP association
with a responder (R) would typically initiate a HIP
exchange by sending an I1 towards the RVS IP address
rather than towards the responder IP address. Then,
the RVS, noticing that the receiver HIT is not its own,
but the HIT of a HIP node registered for the rendezvous
service, would relay the I1 to the responder. Typically
the responder would then complete the exchange without
further assistance from the RVS by sending an R1
directly to the initiator IP address.
</t>
-->
<t>
Currently, most of the Internet applications that need to
communicate with a remote host first translate a domain
name (often obtained via user input) into one or more IP
address(es). This step occurs prior to communication with
the remote host, and relies on a DNS lookup.
</t>
<t>
With HIP, IP addresses are intended to be used
mostly for on-the-wire communication between end
hosts, while most ULPs and applications use HIs or
HITs instead (ICMP might be an example of an ULP
not using them.) Consequently, we need a means to
translate a domain name into an HI. Using the DNS
for this translation is pretty straightforward: We
define a new HIP resource record. Upon
query by an application or ULP for a FQDN -> IP
lookup, the resolver would then additionally
perform an FQDN -> HI lookup, and use it to
construct the resulting HI -> IP mapping (which
is internal to the HIP layer.) The HIP layer uses
the HI -> IP mapping to translate HIs and HITs
into IP addresses and vice versa.
</t>
<t>
The <xref target="I-D.ietf-hip-rvs">HIP
rendezvous extensions</xref> proposal allows a
HIP node to be reached via the IP address(es) of
a third party, the node's rendezvous server (RVS.)
An initiator willing to establish a HIP association
with a responder served by a RVS would typically initiate a HIP
exchange by sending an I1 towards the RVS IP address
rather than towards the responder IP address.
Consequently, we need a means to translate a domain name into
the rendezvous server's domain name.
</t>
<t>
This draft introduces the new HIP DNS Resource Record
to store Rendezvous Server (RVS), Host Identity (HI) and Host Identity Tag (HIT)
information.
</t>
</section>
<section title="Conventions used in this document">
<t>
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 <xref target="RFC2119">RFC2119</xref>.
</t>
</section>
<section title="Usage Scenarios">
<t>
In this section, we briefly introduce a number of usage
scenarios where the DNS is useful with the Host Identity
Protocol.
</t>
<t>
With HIP, most application and ULPs are unaware of the IP
addresses used to carry packets on the wire. Consequently,
a HIP node could take advantage of having multiple IP
addresses for fail-over, redundancy, mobility, or
renumbering, in a manner which is transparent to most ULPs
and applications (because they are bound to HIs, hence they
are agnostic to these IP address changes.)
</t> <t>
In these situations, a node wishing to be reachable by
reference to its FQDN should store the following
information in the DNS:
</t>
<t>
<list style="symbols">
<t>A set of IP address(es) through A <xref target="RFC1035"/>
and AAAA <xref target="RFC3596"/> RRs.</t>
<t>A Host Identity (HI), Host Identity Tag (HIT) and possibly a set of rendezvous server(s) (RVS) through HIP RRs.</t>
</list>
</t>
The HIP RR is class independent.
<t>
</t>
<t>
When a HIP node wants to initiate a communication with
another HIP node, it first needs to perform a HIP base
exchange to set-up a HIP association towards its peer.
Although such an exchange can be initiated
opportunistically, i.e., without prior knowledge of the
responder's HI, by doing so both nodes knowingly risk
man-in-the-middle attacks on the HIP exchange. To prevent
these attacks, it is recommended that the initiator first
obtain the HI of the responder, and then initiate the
exchange. This can be done, for example, through manual
configuration or DNS lookups. Hence, a
new HIP RR is introduced.
</t>
<t>
When a HIP node is frequently changing its IP
address(es), the dynamic DNS update latency may prevent
it from publishing its new IP address(es) in the DNS. For
solving this problem, the <xref target="RFC4423">
HIP architecture</xref> introduces
rendezvous servers (RVS.) A HIP host uses a
rendezvous server as a rendezvous point, to maintain
reachability with possible HIP initiators while moving
<xref target="I-D.ietf-hip-mm"/>. Such a HIP
node would publish in the DNS its RVS domain name(s)
in a HIP RR, while keeping its RVS up-to-date
with its current set of IP addresses.
</t>
<t>
When a HIP node wants to initiate a HIP exchange with a
responder it will perform a number of DNS lookups. Depending
on the type of the implementation, the order in which those lookups
will be issued may vary. For instance, implementations using
HIT in APIS may typically first query for HIP
resource records at the responder FQDN, while those using
IP address in APIs may typically first query for A and/or AAAA
resource records.
</t>
<t>
In the following we assume that the initiator first queries
for HIP resource records at the responder FQDN.
</t>
<t>
If the query for the HIP type was responded to with a DNS
answer with RCODE=3 (Name Error), then the responder's information
is not present in the DNS and further queries SHOULD NOT be made.
</t>
<t>
In case the query for the HIP records returned a DNS answer
with RCODE=0 (No Error), then the initiator sends out one more query for
for A and AAAA types at the responder's FQDN.
</t>
<t>
Depending on the combinations of answer the situations described in
<xref target="single"/> and <xref target="mobile"/> <!--and <xref target="mixed"/>
--> can occur.
</t>
<t>
Note that storing HIP RR information in the DNS at a FQDN
which is assigned to a non-HIP node might have ill
effects on its reachability by HIP nodes.
</t>
<section anchor="single" title="Simple static singly homed end-host">
<t>
A HIP node (R) with a single static network attachment, wishing to be
reachable by reference to its FQDN (www.example.com), would store in the DNS, in
addition to its IP address(es) (IP-R), its Host Identity (HI-R) and Host Identity Tag (HIT-R) in a HIP
resource record.
</t>
<t>
An initiator willing to associate with a node would typically issue the following queries:
<list style="compact">
<t>
QNAME=www.example.com, QTYPE=HIP
</t>
<t>
(QCLASS=IN is assumed and omitted from the examples)
</t>
</list>
Which returns a DNS packet with RCODE=0 and one or more HIP RRs with
the HIT and HI (e.g. HIT-R and HI-R) of the responder in the answer section, but no RVS.
<list style="compact">
<t>
QNAME=www.example.com, QTYPE=A
</t>
</list>
Which returns a DNS packet with RCODE=0 and one or more A or AAAA RRs containing
IP address(es) of the responder (e.g. IP-R) in the answer section.
</t>
<figure title="Static Singly Homed Host">
<artwork>
Caption: In the remainder of this document, for the sake of keeping
diagrams simple and concise, several DNS queries and answers
are represented as one single transaction, while in fact
there are several queries and answers flowing back and
forth, as described in the textual examples.
[HIP? A? ]
[www.example.com] +-----+
+-------------------------------->| |
| | DNS |
| +-------------------------------| |
| | [HIP? A? ] +-----+
| | [www.example.com]
| | [HIP HIT-R HI-R ]
| | [A IP-R ]
| v
+-----+ +-----+
| |--------------I1------------->| |
| I |<-------------R1--------------| R |
| |--------------I2------------->| |
| |<-------------R2--------------| |
+-----+ +-----+
</artwork>
</figure>
<t>
The initiator would then send an I1
to the responder's IP addresses (IP-R.)
</t>
</section>
<section anchor="mobile" title="Mobile end-host">
<t>
A mobile HIP node (R) wishing to be reachable by reference to
its FQDN (www.example.com) would store in the DNS, possibly in addition to its IP
address(es) (IP-R), its HI (HI-R), HIT (HIT-R) and the domain name(s)
of its rendezvous server(s) (rvs.example.com) in HIP resource record(s).
The mobile HIP node also needs to notify its rendezvous
servers of any change in its set of IP address(es).
</t>
<t>
An initiator willing to associate with such mobile node would typically issue the following queries:
<list style="compact">
<t>
QNAME=www.example.com, QTYPE=HIP
</t>
</list>
Which returns a DNS packet with RCODE=0 and one or more HIP RRs with
the HIT, HI and RVS domain name(s) (e.g. HIT-R, HI-R, and rvs.example.com) of the responder in the answer section.
<list style="compact">
<t>
QNAME=rvs.example.com, QTYPE=A
</t>
</list>
Which returns a DNS packet with RCODE=0 and one or more A or AAAA RRs containing
IP address(es) of the responder's RVS (e.g. IP-RVS) in the answer section.
</t>
<!--<t>
QNAME=www.example.com, QTYPE=A
</t>
</list>
Which returns a DNS packet with RCODE=0 and an empty answer section.
-->
<figure title="Mobile End-Host">
<artwork>
[HIP? ]
[www.example.com]
[A? ]
[rvs.example.com] +-----+
+----------------------------------------->| |
| | DNS |
| +----------------------------------------| |
| | [HIP? ] +-----+
| | [www.example.com ]
| | [HIP HIT-R HI-R rvs.example.com]
| |
| | [A? ]
| | [rvs.example.com]
| | [A IP-RVS ]
| |
| | +-----+
| | +------I1----->| RVS |-----I1------+
| | | +-----+ |
| | | |
| | | |
| v | v
+-----+ +-----+
| |<---------------R1------------| |
| I |----------------I2----------->| R |
| |<---------------R2------------| |
+-----+ +-----+
</artwork>
</figure>
<t>
The initiator would then send an
I1 to the RVS IP address (IP-RVS.) Following, the RVS will relay the I1
up to the mobile node's IP address (IP-R), which will complete the HIP
exchange.
</t>
</section>
<!--
<section anchor="mixed" title="Mixed Scenario">
<t>
A HIP node might be configured with more than one IP address (multi-homed),
or rendezvous server (multi-reachable.) In these cases, it
is possible that the DNS returns multiple A or AAAA RRs, as well as
HIP RRs containing one or multiple rendezvous servers.
In addition to its set of IP address(es) (IP-R), a multi-homed
end-host would store in the DNS its HI (HI-R), HIT (HIT-R) and domain name(s)
of its RVS(s) (rvs.example.com) in HIP RRs.
</t>
<t>
An initiator willing to associate with such mobile node would typically issue the following queries:
<list style="compact">
<t>
QNAME=www.example.com, QTYPE=HIP
</t>
</list>
Which returns a DNS packet with RCODE=0 and one or more HIP RRs with
the HIT, HI and RVS domain name(s) (e.g. HIT-R, HI-R, and rvs.example.com) of the responder in the answer section.
</t>
<list style="compact">
<t>
QNAME=rvs.example.com, QTYPE=A
</t>
</list>
Which returns a DNS packet with RCODE=0 and one or more A or AAAA RRs containing
IP address(es) of the responder's RVS (e.g. IP-RVS) in the answer section.
<list style="compact">
<t>
QNAME=www.example.com, QTYPE=A
</t>
</list>
Which returns a DNS packet with RCODE=0 and one or more A or AAAA RRs containing
IP address(es) of the responder (e.g. IP-R) in the answer section.
<figure title="Multi-Homed End-host or Site">
<artwork>
[HIP? ]
[www.example.com]
[A? ]
[rvs.example.com] +-----+
+----------------------------------------->| |
| | DNS |
| +----------------------------------------| |
| | [A? HIP? ] +-----+
| | [www.example.com ]
| | [A IP-R ]
| | [HIP HIT-R HI-R rvs.example.com]
| |
| | [A? ]
| | [rvs.example.com]
| | [A IP-RVS ]
| |
| | +-----+
| | +------I1----->| RVS |-----I1------+
| | | +-----+ |
| | | |
| | | |
| v | v
+-----+ +-----+
| |----------------I1----------->| |
| |<---------------R1------------| |
| I |----------------I2----------->| R |
| |<---------------R2------------| |
+-----+ +-----+
</artwork>
</figure>
<t>
The initiator would then typically send the same I1
to both the RVS and the responder's IP addresses (IP-RVS and IP-R.)
</t>
</section>
-->
</section>
<section anchor="sec-overview-functionality"
title="Overview of using the DNS with HIP">
<section title="Storing HI, HIT and RVS in DNS">
<t>
Any conforming implementation may store a Host Identity (HI) and its associated
Host Identity Tag (HIT) in a DNS HIP RDATA format. If a particular form of
an HI does not already have a specified RDATA format, a new RDATA-like format
SHOULD be defined for the HI. HI and HIT are defined in Section 3 of <xref
target="I-D.ietf-hip-base"/>.
</t>
<!-- <section title="Different types of HITs">
<t>
There are two types of HITs. HITs of the first type, called Type 1
HIT, consist of an 8-bit prefix followed by 120 bits of the hash of
the public key. HITs of the second type (Type 2 HIT) consist of a
Host Assigning Authority Field (HAA), and only the last 64 bits come
from a SHA-1 hash of the Host Identity. This latter format for HIT
is recommended for 'well known' systems. It is possible to support a
resolution mechanism for these names in hierarchical directories,
like the DNS.
</t><t>
This document fully specifies only Type 2 HITs. Type 1 HITs
are specified in Section 3.1 of <xref target="I-D.ietf-hip-base"/>.
</t><t>
Note that the format how HITs are stored in the HIPHI RRs may be
different form the format actually used in protocols,
the HIP base exchange <xref target="I-D.ietf-hip-base"/> included. This is because
the DNS RR explicitly contains the HIT type and algorithm,
while some protocols may prefer to use a prefix
to indicate the HIT type. The implementations
are expected to use the actual HI when comparing
Host Identities. </t>
<section title="Host Assigning Authority (HAA) field">
<t>
The 64 bits of HAA supports two levels of delegation. The
first is a registered assigning authority (RAA). The second is
a registered identity (RI, commonly a company). The RAA is 24
bits with values assign sequentially by ICANN. The RI is 40
bits, also assigned sequentially but by the RAA.</t>
</section>
<section title="Storing HAA in HIPHI Resource Records">
<t>
Any conforming implementation may store a domain name Host Assigning Authority
(HAA) in a DNS HIPHI RDATA format. A HAA MUST be stored like a Type 2 HIT,
while the least significant bits of the HIT
extracted from the HI hash output are set to zero, the Host Identity Length is
set zero, and the Host Identity field is omitted. If a particular form of a HAA
does not already have an associated HIT specified RDATA format, a new
RDATA-like format SHOULD be defined for the HIT/HAA.
</t>
</section>
-->
<t>
Upon return of a HIP RR, a host MUST always calculate the
HI-derivative HIT to be used in the HIP exchange, as specified in Section 3
of the
<xref target="I-D.ietf-hip-base">HIP base specification</xref>, while
the HIT possibly embedded along SHOULD only be used as an
optimization (e.g. table lookup.)
</t>
<t>
The HIP resource record may also contain
one or more domain name(s) of rendezvous
server(s) towards which HIP I1 packets might be sent to
trigger the establishment of an association with the
entity named by this resource record <xref
target="I-D.ietf-hip-rvs"/>.
</t>
<t>
The rendezvous server field of the HIP resource record stored at a
given domain name MAY include the domain name itself. A semantically
equivalent situation occurs if no rendezvous server is stored in the
HIP resource record of that domain.
Such situations occurs in two cases:
<list style="symbols">
<t>The host is mobile, and the A and/or AAAA resource record(s) stored
at its domain name contains the IP address(es) of its rendezvous
server rather than its own one.</t>
<t>The host is stationary, and can be reached directly at IP
address(es) contained in A and/or AAAA resource record(s) stored at
its domain name. This a degenerated case of rendezvous service where
the host somewhat acts as a rendezvous server for itself.</t>
</list>
</t>
<t>
An RVS receiving such an I1 would then relay it to the appropriate
responder (the owner of the I1 receiver HIT.) The responder will then
complete the exchange with the initiator, typically without ongoing help
from the RVS.
</t>
</section>
<section title="Initiating connections based on DNS names">
<t>
On a HIP node, a Host Identity Protocol exchange SHOULD
be initiated whenever an Upper Layer Protocol attempts to
communicate with an entity and the DNS lookup returns
HIP resource records.
</t>
</section>
</section>
<section anchor="rdata" title="HIP RR Storage Format">
<t>
The RDATA for a HIP RR consists of a public key
algorithm type, the HIT length, a HIT, a public key, and
optionally one or more rendezvous server(s).
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HIT length | PK algorithm | PK length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ HIT ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+ +
| Public Key |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Rendezvous Servers ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+
</artwork>
</t>
<t>
The HIT length, PK algorithm, PK length, HIT and Public Key field are REQUIRED.
The Rendezvous Servers field is OPTIONAL.
</t>
<!-- <artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HIT type | HIT algorithm | PK algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HIT |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ Public Key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
</artwork>
-->
<!--
<section anchor="hitt-rdata" title="HIT type format">
<t>
The HIT type field indicates the Host Identity Tag (HIT) type
and the implied HIT format.
</t>
<t>
The following values are defined:
</t>
<t><list style="empty">
<t>0 No HIT is present</t>
<t>1 A Type 1 HIT is present</t>
<t>2 A Type 2 HIT is present</t>
<t>3-6 Unassigned</t>
<t>7 A HAA is present</t>
</list>
</t>
-->
<section anchor="hita-rdata" title="HIT length format">
<t>
The HIT length indicates the length in bytes of the HIT field.
This is an 8 bits unsigned integer.
</t>
</section>
<section anchor="alg-rdata" title="PK algorithm format ">
<t>
The PK algorithm field indicates the public key
cryptographic algorithm and the implied public key field format.
This is an 8 bits unsigned integer.
This document reuses the values defined for the 'algorithm
type' of the <xref target="RFC4025">
IPSECKEY RR</xref>
'gateway type' field.
</t>
<t>
The presently defined values are shown here for reference:
</t>
<t> <list style="empty">
<t>1 A DSA key is present, in the format defined in <xref target="RFC2536">RFC2536</xref>.</t>
<t>2 A RSA key is present, in the format defined in <xref target="RFC3110">RFC3110</xref>.</t>
</list></t>
</section>
<section anchor="hitpk-rdata" title="PK length format">
<t>
The PK length indicates the length in bytes
of the Public key field. This is a 16 bits unsigned integer in network byte order.
</t>
</section>
<section anchor="hittype-rdata" title="HIT format">
<t>
The HIT is stored, as a binary value, in network byte order.
</t>
</section>
<section anchor="pk-rdata" title="Public key format">
<t>
Both of the public key types defined in this document
(RSA
and DSA) reuse the public key formats defined for
the <xref target="RFC4025">
IPSECKEY RR</xref> (which in turns
contains the algorithm-specific portion of the KEY RR
RDATA, all of the KEY RR DATA after the first four
octets, corresponding to the same portion of the KEY RR
that must be specified by documents that define a DNSSEC
algorithm.)
</t>
<t>
In the future, if a new algorithm is to be used both by
IPSECKEY RR and HIP RR, it should use the
same public key encoding for both RRs. Unless specified
otherwise, the HIP RR public key field SHOULD use
the same public key format as the IPSECKEY RR RDATA
for the corresponding algorithm.
</t>
<t>The DSA key format is defined in <xref target="RFC2536">RFC2536</xref>.</t>
<t>The RSA key format is defined in <xref
target="RFC3110">RFC3110</xref> and the RSA key
size limit (4096 bits) is relaxed in the <xref
target="RFC4025"> IPSECKEY
RR</xref> specification.</t>
</section>
<section anchor="hiprvs-rdata" title="Rendezvous servers format">
<t>
The Rendezvous servers field indicates one or more variable length wire-encoded domain names
rendezvous server(s), as
described in Section 3.3 of <xref
target="RFC1035">RFC1035</xref>. The wire-encoded format is
self-describing, so the length is implicit. The
domain names MUST NOT be compressed. The
rendezvous server(s) are listed in order of preference (i.e. first rendezvous
server(s) are preferred). </t>
</section>
</section>
<section title="HIP RR Presentation Format">
<t>
This section specifies the representation of the HIP
RR in a zone data master file.
</t>
<t>
The HIT length field is not represented as it is implicitly known
thanks to the HIT field representation.
</t>
<t>
The PK algorithm field is represented
as unsigned integers.
</t>
<t>
The PK length field is not represented as it is implicitly known
thanks to the Public key field representation.
</t>
<t>
The HIT field is represented as the <xref
target="RFC4648">Base16 encoding</xref> (a.k.a.
hex or hexadecimal) of the HIT. The encoding
MUST NOT contain whitespace(s). <!-- If no HIT is to be
indicated, then the HIT algorithm MUST be zero and the HIT
field must be "." (a single dot character).-->
</t>
<t>
The Public Key field is represented as the <xref
target="RFC4648">Base64 encoding</xref> of the
public key. The encoding MAY contain whitespace(s), and
such whitespace(s) MUST be ignored.
</t>
<t>The Rendezvous servers field is represented by one or more
uncompressed domain name(s)</t>
<t>
The complete representation of the HPIHI record is:
<artwork>
IN HIP ( pk-algorithm
base16-encoded-hit
base64-encoded-public-key
rendezvous-server[1]
...
rendezvous-server[n] )
</artwork>
</t>
</section>
<section title="Examples">
<!-- <t>
Example of a node with a HI but no HIT:
<artwork>
www.example.com IN HIPHI ( 0 1 2
.
AB3NzaC1kc3MAAACBAOBhKn
TCPOuFBzZQX/N3O9dm9P9iv
UIMoId== )
</artwork>
</t>
-->
<t>
Example of a node with HI and HIT but no RVS:
<artwork>
www.example.com. IN HIP ( 2 4009D9BA7B1A74DF365639CC39F1D578
AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIv
M4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy
87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRG
Qb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48A
WkskmdHaVDP4BcelrTI3rMXdXF5D )
</artwork>
</t>
<t>
Example of a node with a HI, HIT and one RVS:
<artwork>
www.example.com. IN HIP ( 2 4009D9BA7B1A74DF365639CC39F1D578
AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIv
M4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy
87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRG
Qb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48A
WkskmdHaVDP4BcelrTI3rMXdXF5D
rvs.example.com )
</artwork>
</t>
<t>
Example of a node with a HI, HIT and two RVS:
<artwork>
www.example.com. IN HIP ( 2 4009D9BA7B1A74DF365639CC39F1D578
AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIv
M4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy
87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRG
Qb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48A
WkskmdHaVDP4BcelrTI3rMXdXF5D
rvs1.example.com
rvs2.example.com )
</artwork>
</t>
</section>
<!--
<section title="Retrieving Multiple HITs and IPs from the DNS">
<t>
If a host receives multiple HITs in a response to a DNS query, those
HITs MUST be considered to denote a single service, and be semantically
equivalent from that point of view. When initiating a base exchange
with the denoted service, the host SHOULD be prepared to accept any of
HITs as the peer's identity. A host MAY implement this by using the
opportunistic mode (destination HIT null in I1), or by sending multiple
I1s, if needed.
</t><t>
In particular, if a host receives multiple HITs and multiple IP
addresses in response to a DNS query, the host cannot know how the
HITs are reachable at the listed IP addresses. The mapping may be
any, i.e., all HITs may be reachable at all of the listed IP
addresses, some of the HITs may be reachable at some of the IP
addresses, or there may even be one-to-one mapping between the HITs
and IP addresses. In general, the host cannot know the mapping and
MUST NOT expect any particular mapping.
</t><t>
It is RECOMMENDED that if a host receives multiple HITs, the host
SHOULD first try to initiate the base exchange by using the
opportunistic mode. If the returned HIT does not match with any of the
expected HITs, the host SHOULD retry by sending further I1s, one at
time, trying out all of the listed HITs. If the host receives an R1
for any of the I1s, the host SHOULD continue to use the successful IP
address until an R1 with a listed HIT is received, or the host has
tried all HITs, and try the other IP addresses only after that. A host
MAY also send multiple I1s in parallel, but sending such I1s MUST be
rate limited to avoid flooding (as per Section 8.4.1 of <xref
target="I-D.ietf-hip-base"/>). </t>
</section>
-->
<!-- <section anchor="trans-cons" title="Transition mechanisms">
<t>
During a transition period, to allows to store the HIP informations of
a node in a DNS server which does not support the HIPHI and HIPRVS
RRs, A and AAAA RRs MAY be overloaded. A HIT would typically be stored
in a AAAA RR and a RVS in either a A or AAAA RR. If such a situation
occurs, the overloaded RRs MUST be returned as the last items of the
returned RRs set (A or AAAA), to avoid as most as possible conflicts
with non-HIP IPv6 nodes.
</t>
</section>
-->
<section anchor="sec-cons" title="Security Considerations">
<t>
Though the security considerations of the HIP DNS
extensions still need to be more investigated and
documented, this section contains a description of the
known threats involved with the usage of the HIP DNS
extensions.
</t> <t>
In a manner similar to the <xref
target="RFC4025"> IPSECKEY RR</xref>,
the HIP DNS Extensions allows to provision two HIP nodes
with the public keying material (HI) of their peer. These
HIs will be subsequently used in a key exchange between the
peers. Hence, the HIP DNS Extensions introduce the same
kind of threats that IPSECKEY does, plus threats caused by
the possibility given to a HIP node to initiate or accept a
HIP exchange using "opportunistic" or "unpublished
initiator HI" modes.
</t>
<t>
A HIP node SHOULD obtain HIP RRs
from a trusted party trough a secure channel insuring
proper data integrity of the RRs. DNSSEC
<xref target="RFC4033"/>
<xref target="RFC4034"/>
<xref target="RFC4035"/>
provides such a secure channel.
</t>
<t>
In the absence of a proper secure channel, both
parties are vulnerable to MitM and DoS attacks, and
unrelated parties might be subject to DoS attacks
as well. These threats are described in the following
sections.
</t>
<section title="Attacker tampering with an insecure HIP RR">
<t>
The HIP RR contains public keying material in the
form of the named peer's public key (the HI) and its
secure hash (the HIT.) Both of these are not sensitive
to attacks where an adversary gains knowledge of them.
However, an attacker that is able to mount an active
attack on the DNS, i.e., tampers with this HIP RR
(e.g. using DNS spoofing) is able to mount
Man-in-the-Middle attacks on the cryptographic core of
the eventual HIP exchange (responder's HIP RR
rewritten by the attacker.)
</t>
<t>
The HIP RR may contain a rendezvous server domain name resolved into a destination IP address where the
named peer is reachable by an I1 (HIP Rendezvous
Extensions
<xref target="I-D.ietf-hip-rvs">
IPSECKEY RR</xref>.)
Thus, an attacker able to tamper with this RR
is able to redirect I1 packets sent
to the named peer to a chosen IP address, for
DoS or MitM attacks. Note that this kind of attack
is not specific to HIP and exists independently to
whether or not HIP and the HIP RR are used. Such an
attacker might tamper with A and AAAA RRs as well.
</t>
<t>
An attacker might obviously use these two
attacks in conjunction: It will replace the
responder's HI and RVS IP address by its owns
in a spoofed DNS packet sent to the initiator HI,
then redirect all exchanged packets to him
and mount a MitM on HIP. In this case HIP won't
provide confidentiality nor initiator HI protection
from eavesdroppers.
</t>
</section>
<!-- <section title="Opportunistic HIP">
<t>
A HIP initiator may not be aware of its peer's HI, and/or
its HIT (e.g. because the DNS does not contains HIP
material, or the resolver isn't HIP-enabled), and attempt
an opportunistic HIP exchange towards its known IP
address, filling the responder HIT field with zeros in
the I1 header. Such an initiator is vulnerable to a MitM
attack because it can't validate the HI and HIT contained
in a replied R1. Hence, an implementation MAY choose not
to use opportunistic mode.
</t>
</section>
<section title="Unpublished Initiator HI">
<t>
A HIP initiator may choose to use an unpublished HI,
which is not stored in the DNS by means of a HIPHI
RR. A responder associating with such an initiator
knowingly risks a MitM attack because it cannot
validate the initiator's HI. Hence, an implementation
MAY choose not to use unpublished mode.
</t>
</section>
-->
<section title="Hash and HITs Collisions">
<t>
As many cryptographic algorithm, some secure
hashes (e.g. SHA1, used by HIP to generate a HIT
from an HI) eventually become insecure, because an
exploit has been found in which an attacker with
a reasonable computation power breaks one of the
security features of the hash (e.g. its supposed
collision resistance.) This is why a HIP end-node
implementation SHOULD NOT authenticate its HIP
peers based solely on a HIT retrieved from DNS,
but SHOULD rather use HI-based authentication.
</t>
</section>
<section title="DNSSEC">
<t>
In the absence of DNSSEC, the HIP RR is subject to the
threats described in <xref target="RFC3833">RFC 3833</xref>.
</t>
</section>
</section>
<section title="IANA Considerations">
<t>
IANA should allocate one new RR type code (TBD, 55?) for the HIP RR
from the standard RR type space.
</t>
<t>
IANA does not need to open a new registry for
public key algorithms of the HIP RR because the HIP RR reuses "algorithms
types" defined for the <xref target="RFC4025">IPSECKEY RR
</xref>.
The presently defined values are shown here for reference:
</t>
<t><list style="compact">
<t>
0 is reserved
</t>
<t>
1 is RSA
</t>
<t>
2 is DSA
</t>
</list></t>
</section>
<section title="Acknowledgments">
<t>
As usual in the IETF, this document is the result of a
collaboration between many people. The authors would like to
thanks the author (Michael Richardson), contributors and
reviewers of the <xref target="RFC4025">IPSECKEY
RR</xref> specification, which this document was framed
after. The authors would also like to thanks the following
people, who have provided thoughtful and helpful discussions
and/or suggestions, that have helped improving this document:
Jeff Ahrenholz, Rob Austein, Hannu Flinck, Tom Henderson, Olaf Kolkman, Miika Komu, Andrew
McGregor, Erik Nordmark, and Gabriel Montenegro. Some parts of
this draft stem from <xref target="I-D.ietf-hip-base" />.
</t>
<t>
Julien Laganier is partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission.
</t>
</section>
</middle>
<back>
<references title="Normative references">
&RFC1034;
&RFC1035;
&RFC2119;
&RFC2536;
&RFC3110;
&RFC3596;
&RFC4025;
&RFC4033;
&RFC4034;
&RFC4035;
&RFC4648;
&I-D.ietf-hip-base;
&I-D.ietf-hip-rvs;
</references>
<references title="Informative references">
&RFC4423;
<!--&I-D.jokela-hip-esp;-->
&I-D.ietf-hip-mm;
&RFC3833;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 10:16:46 |