draft-ietf-hip-dns-05.txt   draft-ietf-hip-dns-06.txt 
Network Working Group P. Nikander Network Working Group P. Nikander
Internet-Draft Ericsson Research Nomadic Lab Internet-Draft Ericsson Research Nomadic Lab
Expires: August 20, 2006 J. Laganier Expires: August 28, 2006 J. Laganier
DoCoMo Euro-Labs DoCoMo Euro-Labs
February 16, 2006 February 24, 2006
Host Identity Protocol (HIP) Domain Name System (DNS) Extensions Host Identity Protocol (HIP) Domain Name System (DNS) Extensions
draft-ietf-hip-dns-05 draft-ietf-hip-dns-06
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 August 20, 2006. This Internet-Draft will expire on August 28, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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
skipping to change at page 9, line 21 skipping to change at page 9, line 21
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].
Upon return of a HIP RR, a host MUST always calculate the HI- 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 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 contain 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 The rendezvous server field of the HIP resource record stored at a
given domain name MAY include the domain name itself. A semantically given domain name MAY include the domain name itself. A semantically
equivalent situation occurs if no rendezvous server is stored in the equivalent situation occurs if no rendezvous server is stored in the
HIP resource record of that domain. Such situations occurs in two HIP resource record of that domain. Such situations occurs in two
cases: cases:
skipping to change at page 9, line 49 skipping to change at page 9, line 49
where the host somewhat acts as a rendezvous server for itself. 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 attempts to communicate with an
entity and the DNS lookup returns HIP resource records. entity and the DNS lookup returns HIP resource records.
5. HIP RR Storage Format 5. HIP RR Storage Format
The RDATA for a HIP RR consists of a public key algorithm type, the The RDATA for a HIP RR consists of a public key algorithm type, the
HIT length, a HIT, a public key, and optionnally one or more HIT length, a HIT, a public key, and optionally one or more
rendezvous server(s). rendezvous server(s).
0 1 2 3 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 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 length | PK algorithm | PK length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ HIT ~ ~ HIT ~
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+ +
| Public Key | | Public Key |
~ ~ ~ ~
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 40 skipping to change at page 10, line 40
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
The HIT length, PK algorithm, PK length, HIT and Public Key field are The HIT length, PK algorithm, PK length, HIT and Public Key field are
REQUIRED. The Rendezvous Servers field is OPTIONAL. REQUIRED. The Rendezvous Servers field is OPTIONAL.
5.1. HIT length format 5.1. HIT length format
The HIT length indicates the length in bytes of the HIT field. The HIT length indicates the length in bytes of the HIT field. This
is an 8 bits unsigned integer.
5.2. PK algorithm format 5.2. PK algorithm format
The PK algorithm field indicates the public key cryptographic The PK algorithm field indicates the public key cryptographic
algorithm and the implied public key field format. This document algorithm and the implied public key field format. This is an 8 bits
reuses the values defined for the 'algorithm type' of the IPSECKEY RR unsigned integer. This document reuses the values defined for the
[RFC4025] 'gateway type' field. 'algorithm type' of the IPSECKEY RR [RFC4025] 'gateway type' field.
The presently defined values are shown here for reference: The presently defined values are shown here for reference:
1 A DSA key is present, in the format defined in RFC2536 1 A DSA key is present, in the format defined in RFC2536
[RFC2536]. [RFC2536].
2 A RSA key is present, in the format defined in RFC3110 2 A RSA key is present, in the format defined in RFC3110
[RFC3110]. [RFC3110].
5.3. PK length format 5.3. PK length format
The PK length indicates the length in bytes of the Public key field. The PK length indicates the length in bytes of the Public key field.
This is a 16 bits unsigned integer in network byte order.
5.4. HIT format 5.4. HIT format
The HIT is stored, as a binary value, in network byte order. The HIT is stored, as a binary value, in network byte order.
5.5. Public key format 5.5. Public key format
Both of the public key types defined in this document (RSA and DSA) Both of the public key types defined in this document (RSA and DSA)
reuse the public key formats defined for the IPSECKEY RR [RFC4025] reuse the public key formats defined for the IPSECKEY RR [RFC4025]
(which in turns contains the algorithm-specific portion of the KEY RR (which in turns contains the algorithm-specific portion of the KEY RR
skipping to change at page 13, line 9 skipping to change at page 13, line 9
base16-encoded-hit base16-encoded-hit
base64-encoded-public-key base64-encoded-public-key
rendezvous-server[1] rendezvous-server[1]
... ...
rendezvous-server[n] ) rendezvous-server[n] )
7. Examples 7. Examples
Example of a node with HI and HIT but no RVS: Example of a node with HI and HIT but no RVS:
www.example.com IN HIP ( 2 2A20E0FF0FE8A52422D059FFFEA938A1 www.example.com. IN HIP ( 2 4009D9BA7B1A74DF365639CC39F1D578
AB3NzaC1kc3MAAACBAOBhKn AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIv
TCPOuFBzZQX/N3O9dm9P9iv M4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy
UIMoId== ) 87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRG
Qb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48A
WkskmdHaVDP4BcelrTI3rMXdXF5D )
Example of a node with a HI, HIT and one RVS: Example of a node with a HI, HIT and one RVS:
www.example.com IN HIP ( 2 2A20E0FF0FE8A52422D059FFFEA938A1 www.example.com. IN HIP ( 2 4009D9BA7B1A74DF365639CC39F1D578
AB3NzaC1kc3MAAACBAOBhKn AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIv
TCPOuFBzZQX/N3O9dm9P9iv M4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy
UIMoId== 87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRG
Qb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48A
WkskmdHaVDP4BcelrTI3rMXdXF5D
rvs.example.com ) rvs.example.com )
Example of a node with a HI, HIT and two RVS: Example of a node with a HI, HIT and two RVS:
www.example.com IN HIP ( 2 2A20E0FF0FE8A52422D059FFFEA938A1 www.example.com. IN HIP ( 2 4009D9BA7B1A74DF365639CC39F1D578
AB3NzaC1kc3MAAACBAOBhKn AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIv
TCPOuFBzZQX/N3O9dm9P9iv M4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy
UIMoId== 87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRG
Qb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48A
WkskmdHaVDP4BcelrTI3rMXdXF5D
rvs1.example.com rvs1.example.com
rvs2.example.com ) rvs2.example.com )
8. Security Considerations 8. Security Considerations
Though the security considerations of the HIP DNS extensions still Though the security considerations of the HIP DNS extensions still
need to be more investigated and documented, this section contains a need to be more investigated and documented, this section contains a
description of the known threats involved with the usage of the HIP description of the known threats involved with the usage of the HIP
DNS extensions. DNS extensions.
skipping to change at page 16, line 7 skipping to change at page 16, line 7
solely on a HIT retrieved from DNS, but SHOULD rather use HI-based solely on a HIT retrieved from DNS, but SHOULD rather use HI-based
authentication. authentication.
8.3. DNSSEC 8.3. DNSSEC
In the absence of DNSSEC, the HIP RR is subject to the threats In the absence of DNSSEC, the HIP RR is subject to the threats
described in RFC 3833 [RFC3833]. described in RFC 3833 [RFC3833].
9. IANA Considerations 9. IANA Considerations
IANA should allocate one new RR type code for the HIP RR from the IANA should allocate one new RR type code (TBD, 55?) for the HIP RR
standard RR type space. from the standard RR type space.
IANA does not need to open a new registry for public key algorithms 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 of the HIP RR because the HIP RR reuses "algorithms types" defined
for the IPSECKEY RR [RFC4025]. The presently defined values are for the IPSECKEY RR [RFC4025]. The presently defined values are
shown here for reference: shown here for reference:
0 is reserved 0 is reserved
1 is RSA 1 is RSA
2 is DSA 2 is DSA
10. Acknowledgments 10. Acknowledgments
As usual in the IETF, this document is the result of a collaboration As usual in the IETF, this document is the result of a collaboration
between many people. The authors would like to thanks the author between many people. The authors would like to thanks the author
(Michael Richardson), contributors and reviewers of the IPSECKEY RR (Michael Richardson), contributors and reviewers of the IPSECKEY RR
[RFC4025] specification, which this document was framed after. The [RFC4025] specification, which this document was framed after. The
authors would also like to thanks the following people, who have authors would also like to thanks the following people, who have
provided thoughtful and helpful discussions and/or suggestions, that provided thoughtful and helpful discussions and/or suggestions, that
have helped improving this document: Rob Austein, Hannu Flinck, Tom have helped improving this document: Jeff Ahrenholz, Rob Austein,
Henderson, Olaf Kolkman, Miika Komu, Andrew McGregor, Erik Nordmark, Hannu Flinck, Tom Henderson, Olaf Kolkman, Miika Komu, Andrew
and Gabriel Montenegro. Some parts of this draft stem from McGregor, Erik Nordmark, and Gabriel Montenegro. Some parts of this
[I-D.ietf-hip-base]. draft stem from [I-D.ietf-hip-base].
Julien Laganier is partly funded by Ambient Networks, a research Julien Laganier is partly funded by Ambient Networks, a research
project supported by the European Commission under its Sixth project supported by the European Commission under its Sixth
Framework Program. The views and conclusions contained herein are Framework Program. The views and conclusions contained herein are
those of the authors and should not be interpreted as necessarily those of the authors and should not be interpreted as necessarily
representing the official policies or endorsements, either expressed representing the official policies or endorsements, either expressed
or implied, of the Ambient Networks project or the European or implied, of the Ambient Networks project or the European
Commission. Commission.
11. References 11. References
 End of changes. 16 change blocks. 
31 lines changed or deleted 39 lines changed or added

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