draft-ietf-hip-dns-04.txt   draft-ietf-hip-dns-05.txt 
Network Working Group P. Nikander Network Working Group P. Nikander
Internet-Draft Ericsson Research Nomadic Lab Internet-Draft Ericsson Research Nomadic Lab
Expires: June 19, 2006 J. Laganier Expires: August 20, 2006 J. Laganier
DoCoMo Euro-Labs DoCoMo Euro-Labs
December 16, 2005 February 16, 2006
Host Identity Protocol (HIP) Domain Name System (DNS) Extensions Host Identity Protocol (HIP) Domain Name System (DNS) Extensions
draft-ietf-hip-dns-04 draft-ietf-hip-dns-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 19, 2006. This Internet-Draft will expire on August 20, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies a new resource record (RR) for the Domain This document specifies a new resource record (RR) for the Domain
Name System (DNS), and how to use it with the Host Identity Protocol 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 (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 Identity (HI, the public component of the node public-private key
pair), Host Identity Tag (HIT, a truncated hash of its public key), pair), Host Identity Tag (HIT, a truncated hash of its public key),
and the Domain Names of its rendezvous servers (RVS.) and the Domain Names of its rendezvous servers (RVS.)
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Simple static singly homed end-host . . . . . . . . . . . 6 3.1. Simple static singly homed end-host . . . . . . . . . . . 6
3.2. Mobile end-host . . . . . . . . . . . . . . . . . . . . . 7 3.2. Mobile end-host . . . . . . . . . . . . . . . . . . . . . 7
3.3. Mixed Scenario . . . . . . . . . . . . . . . . . . . . . . 8 4. Overview of using the DNS with HIP . . . . . . . . . . . . . . 9
4. Overview of using the DNS with HIP . . . . . . . . . . . . . . 11 4.1. Storing HI, HIT and RVS in DNS . . . . . . . . . . . . . . 9
4.1. Storing HI, HIT and RVS in DNS . . . . . . . . . . . . . . 11 4.2. Initiating connections based on DNS names . . . . . . . . 9
4.2. Initiating connections based on DNS names . . . . . . . . 11 5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 10
5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 12 5.1. HIT length format . . . . . . . . . . . . . . . . . . . . 10
5.1. HIT length format . . . . . . . . . . . . . . . . . . . . 12 5.2. PK algorithm format . . . . . . . . . . . . . . . . . . . 10
5.2. PK algorithm format . . . . . . . . . . . . . . . . . . . 12 5.3. PK length format . . . . . . . . . . . . . . . . . . . . . 11
5.3. PK length format . . . . . . . . . . . . . . . . . . . . . 13 5.4. HIT format . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. HIT format . . . . . . . . . . . . . . . . . . . . . . . . 13 5.5. Public key format . . . . . . . . . . . . . . . . . . . . 11
5.5. Public key format . . . . . . . . . . . . . . . . . . . . 13 5.6. Rendezvous servers format . . . . . . . . . . . . . . . . 11
5.6. Rendezvous servers format . . . . . . . . . . . . . . . . 13 6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . . 12
6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . . 14 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8.1. Attacker tampering with an insecure HIP RR . . . . . . . . 14
8.1. Attacker tampering with an insecure HIP RR . . . . . . . . 16 8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . . 15
8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . . 17 8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative references . . . . . . . . . . . . . . . . . . . 18
11.1. Normative references . . . . . . . . . . . . . . . . . . . 20 11.2. Informative references . . . . . . . . . . . . . . . . . . 19
11.2. Informative references . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
This document specifies a new resource record (RR) for the Domain This document specifies a new resource record (RR) for the Domain
Name System (DNS) [RFC1034], and how to use it with the Host Identity Name System (DNS) [RFC1034], and how to use it with the Host Identity
Protocol (HIP) [I-D.ietf-hip-base]. This RR allows a HIP node to Protocol (HIP) [I-D.ietf-hip-base]. This RR allows a HIP node to
store in the DNS its Host Identity (HI, the public component of the store in the DNS its Host Identity (HI, the public component of the
node public-private key pair), Host Identity Tag (HIT, a truncated node public-private key pair), Host Identity Tag (HIT, a truncated
hash of its HI), and the Domain Names of its rendezvous servers hash of its HI), and the Domain Names of its rendezvous servers
(RVS.) [I-D.ietf-hip-rvs] (RVS.) [I-D.ietf-hip-rvs]
skipping to change at page 5, line 48 skipping to change at page 5, line 48
address(es) in the DNS. For solving this problem, the HIP address(es) in the DNS. For solving this problem, the HIP
architecture introduces rendezvous servers (RVS.) A HIP host uses a architecture introduces rendezvous servers (RVS.) A HIP host uses a
rendezvous server as a rendezvous point, to maintain reachability rendezvous server as a rendezvous point, to maintain reachability
with possible HIP initiators. Such a HIP node would publish in the with possible HIP initiators. Such a HIP node would publish in the
DNS its RVS domain name(s) in a HIP RR, while keeping its RVS up-to- DNS its RVS domain name(s) in a HIP RR, while keeping its RVS up-to-
date with its current set of IP addresses. date with its current set of IP addresses.
When a HIP node wants to initiate a HIP exchange with a responder it 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 will perform a number of DNS lookups. Depending on the type of the
implementation, the order in which those lookups will be issued may implementation, the order in which those lookups will be issued may
vary. For instance, implementations using IP address in APIs may vary. For instance, implementations using HIT in APIS may typically
typically first query for A and/or AAAA records at the responder first query for HIP resource records at the responder FQDN, while
FQDN, while those using HIT in APIS may typically first query for HIP those using IP address in APIs may typically first query for A and/or
RRs. AAAA resource records.
In the following we assume that the initiator first queries for A In the following we assume that the initiator first queries for HIP
and/or AAAA records at the responder FQDN. resource records at the responder FQDN.
If the query for the A and/or AAAA was responded to with a DNS answer If the query for the HIP type was responded to with a DNS answer with
with RCODE=3 (Name Error), then the responder's information is not RCODE=3 (Name Error), then the responder's information is not present
present in the DNS and further queries SHOULD NOT be made. in the DNS and further queries SHOULD NOT be made.
In case the query for the address records returned a DNS answer with 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 RCODE=0 (No Error), then the initiator sends out one more query for
for the HIP type at the responder's FQDN. for A and AAAA types at the responder's FQDN.
Depending on the combinations of answer the situations described in Depending on the combinations of answer the situations described in
Section 3.1, Section 3.2 and Section 3.3 can occur. Section 3.1 and Section 3.2 can occur.
Note that storing HIP RR information in the DNS at a FQDN which is 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 assigned to a non-HIP node might have ill effects on its reachability
by HIP nodes. by HIP nodes.
3.1. Simple static singly homed end-host 3.1. Simple static singly homed end-host
A HIP node (R) with a single static network attachment, wishing to be 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 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 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. (HI-R) and Host Identity Tag (HIT-R) in a HIP resource record.
An initiator willing to associate with a node would typically issue An initiator willing to associate with a node would typically issue
the following queries: the following queries:
QNAME=www.example.com, QTYPE=A QNAME=www.example.com, QTYPE=HIP
(QCLASS=IN is assumed and omitted from the examples) (QCLASS=IN is assumed and omitted from the examples)
Which returns a DNS packet with RCODE=0 and one or more A RRs A with
the address of the responder (e.g. IP-R) in the answer section.
QNAME=www.example.com, QTYPE=HIP
Which returns a DNS packet with RCODE=0 and one or more HIP RRs with 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 the HIT and HI (e.g. HIT-R and HI-R) of the responder in the answer
section, but no RVS. section, but no RVS.
QNAME=www.example.com, QTYPE=A
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.
Caption: In the remainder of this document, for the sake of keeping Caption: In the remainder of this document, for the sake of keeping
diagrams simple and concise, several DNS queries and answers diagrams simple and concise, several DNS queries and answers
are represented as one single transaction, while in fact are represented as one single transaction, while in fact
there are several queries and answers flowing back and there are several queries and answers flowing back and
forth, as described in the textual examples. forth, as described in the textual examples.
[A? HIP? ] [HIP? A? ]
[www.example.com] +-----+ [www.example.com] +-----+
+-------------------------------->| | +-------------------------------->| |
| | DNS | | | DNS |
| +-------------------------------| | | +-------------------------------| |
| | [A? HIP? ] +-----+ | | [HIP? A? ] +-----+
| | [www.example.com] | | [www.example.com]
| | [A IP-R ]
| | [HIP HIT-R HI-R ] | | [HIP HIT-R HI-R ]
| | [A IP-R ]
| v | v
+-----+ +-----+ +-----+ +-----+
| |--------------I1------------->| | | |--------------I1------------->| |
| I |<-------------R1--------------| R | | I |<-------------R1--------------| R |
| |--------------I2------------->| | | |--------------I2------------->| |
| |<-------------R2--------------| | | |<-------------R2--------------| |
+-----+ +-----+ +-----+ +-----+
The initiator would then send an I1 to the responder's IP addresses The initiator would then send an I1 to the responder's IP addresses
(IP-R.) (IP-R.)
skipping to change at page 7, line 43 skipping to change at page 7, line 43
A mobile HIP node (R) wishing to be reachable by reference to its 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 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 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 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 resource record(s). The mobile HIP node also needs to notify its
rendezvous servers of any change in its set of IP address(es). rendezvous servers of any change in its set of IP address(es).
An initiator willing to associate with such mobile node would An initiator willing to associate with such mobile node would
typically issue the following queries: typically issue the following queries:
QNAME=www.example.com, QTYPE=A
Which returns a DNS packet with RCODE=0 and an empty answer section.
QNAME=www.example.com, QTYPE=HIP QNAME=www.example.com, QTYPE=HIP
Which returns a DNS packet with RCODE=0 and one or more HIP RRs with 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 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. rvs.example.com) of the responder in the answer section.
QNAME=rvs.example.com, QTYPE=A QNAME=rvs.example.com, QTYPE=A
[A? HIP? ] 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.
[HIP? ]
[www.example.com] [www.example.com]
[A? ] [A? ]
[RVS.example.com] +-----+ [rvs.example.com] +-----+
+----------------------------------------->| | +----------------------------------------->| |
| | DNS | | | DNS |
| +----------------------------------------| | | +----------------------------------------| |
| | [A? HIP? ] +-----+ | | [HIP? ] +-----+
| | [www.example.com ] | | [www.example.com ]
| | [HIP HIT-R HI-R rvs.example.com] | | [HIP HIT-R HI-R rvs.example.com]
| | | |
| | [A? ] | | [A? ]
| | [rvs.example.com] | | [rvs.example.com]
| | [A IP-RVS ] | | [A IP-RVS ]
| | | |
| | +-----+ | | +-----+
| | +------I1----->| RVS |-----I1------+ | | +------I1----->| RVS |-----I1------+
| | | +-----+ | | | | +-----+ |
skipping to change at page 8, line 39 skipping to change at page 9, line 5
+-----+ +-----+ +-----+ +-----+
| |<---------------R1------------| | | |<---------------R1------------| |
| I |----------------I2----------->| R | | I |----------------I2----------->| R |
| |<---------------R2------------| | | |<---------------R2------------| |
+-----+ +-----+ +-----+ +-----+
The initiator would then send an I1 to the RVS IP address (IP-RVS.) 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 Following, the RVS will relay the I1 up to the mobile node's IP
address (IP-R), which will complete the HIP exchange. address (IP-R), which will complete the HIP exchange.
3.3. Mixed Scenario
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-R1, IP-R2), 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.
An initiator willing to associate with such mobile node would
typically issue the following queries:
QNAME=www.example.com, QTYPE=A
Which returns a DNS packet with RCODE=0 and one or more A or AAAA RRs
containing IP address(es) (e.g. IP-R1 and IP-R2) in the answer
section.
QNAME=www.example.com, QTYPE=HIP
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.
QNAME=rvs.example.com, QTYPE=A
[A? 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------------| |
+-----+ +-----+
The initiator would then typically send the same I1 to both the RVS
and the responder's IP addresses (IP-RVS and IP-R.)
4. Overview of using the DNS with HIP 4. Overview of using the DNS with HIP
4.1. Storing HI, HIT and RVS in DNS 4.1. Storing HI, HIT and RVS in DNS
Any conforming implementation may store a Host Identity (HI) and its Any conforming implementation may store a Host Identity (HI) and its
associated Host Identity Tag (HIT) in a DNS HIP RDATA format. If a 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 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 format, a new RDATA-like format SHOULD be defined for the HI. HI and
HIT are defined in Section 3 of [I-D.ietf-hip-base]. HIT are defined in Section 3 of [I-D.ietf-hip-base].
skipping to change at page 11, line 26 skipping to change at page 9, line 26
derivative HIT to be used in the HIP exchange, as specified in derivative HIT to be used in the HIP exchange, as specified in
Section 3 of the HIP base specification [I-D.ietf-hip-base], while Section 3 of the HIP base specification [I-D.ietf-hip-base], while
the HIT possibly embedded along SHOULD only be used as an the HIT possibly embedded along SHOULD only be used as an
optimization (e.g. table lookup.) optimization (e.g. table lookup.)
The HIP resource record may also contains one or more domain name(s) The HIP resource record may also contains one or more domain name(s)
of rendezvous server(s) towards which HIP I1 packets might be sent to of rendezvous server(s) towards which HIP I1 packets might be sent to
trigger the establishment of an association with the entity named by trigger the establishment of an association with the entity named by
this resource record [I-D.ietf-hip-rvs]. this resource record [I-D.ietf-hip-rvs].
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:
o 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.
o 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.
An RVS receiving such an I1 would then relay it to the appropriate An RVS receiving such an I1 would then relay it to the appropriate
responder (the owner of the I1 receiver HIT.) The responder will responder (the owner of the I1 receiver HIT.) The responder will
then complete the exchange with the initiator, typically without then complete the exchange with the initiator, typically without
ongoing help from the RVS. ongoing help from the RVS.
4.2. Initiating connections based on DNS names 4.2. Initiating connections based on DNS names
On a HIP node, a Host Identity Protocol exchange SHOULD be initiated On a HIP node, a Host Identity Protocol exchange SHOULD be initiated
whenever an Upper Layer Protocol attempt to communicate with an whenever an Upper Layer Protocol attempt to communicate with an
entity and the DNS lookup returns HIP resource records. entity and the DNS lookup returns HIP resource records.
skipping to change at page 23, line 41 skipping to change at page 21, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 26 change blocks. 
117 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/