--- 1/draft-ietf-hip-dns-05.txt 2006-02-27 17:12:12.000000000 +0100 +++ 2/draft-ietf-hip-dns-06.txt 2006-02-27 17:12:12.000000000 +0100 @@ -1,19 +1,19 @@ Network Working Group P. Nikander Internet-Draft Ericsson Research Nomadic Lab -Expires: August 20, 2006 J. Laganier +Expires: August 28, 2006 J. Laganier DoCoMo Euro-Labs - February 16, 2006 + February 24, 2006 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions - draft-ietf-hip-dns-05 + draft-ietf-hip-dns-06 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,21 +24,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (C) The Internet Society (2006). Abstract 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 @@ -304,21 +304,21 @@ 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 [I-D.ietf-hip-base]. 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 HIP base specification [I-D.ietf-hip-base], while the HIT possibly embedded along SHOULD only be used as an 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 trigger the establishment of an association with the entity named by 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: @@ -332,34 +332,34 @@ where the host somewhat acts as a rendezvous server for itself. 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. 4.2. Initiating connections based on DNS names 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. 5. HIP RR Storage Format 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). 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 length | PK algorithm | PK length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ HIT ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+ + | Public Key | ~ ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -370,40 +370,42 @@ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+ The HIT length, PK algorithm, PK length, HIT and Public Key field are REQUIRED. The Rendezvous Servers field is OPTIONAL. 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 The PK algorithm field indicates the public key cryptographic - algorithm and the implied public key field format. This document - reuses the values defined for the 'algorithm type' of the IPSECKEY RR - [RFC4025] 'gateway type' field. + 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 IPSECKEY RR [RFC4025] 'gateway type' field. The presently defined values are shown here for reference: 1 A DSA key is present, in the format defined in RFC2536 [RFC2536]. 2 A RSA key is present, in the format defined in RFC3110 [RFC3110]. 5.3. PK length format 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 The HIT is stored, as a binary value, in network byte order. 5.5. Public key format Both of the public key types defined in this document (RSA and DSA) reuse the public key formats defined for the IPSECKEY RR [RFC4025] (which in turns contains the algorithm-specific portion of the KEY RR @@ -462,39 +464,45 @@ base16-encoded-hit base64-encoded-public-key rendezvous-server[1] ... rendezvous-server[n] ) 7. Examples Example of a node with HI and HIT but no RVS: - www.example.com IN HIP ( 2 2A20E0FF0FE8A52422D059FFFEA938A1 - AB3NzaC1kc3MAAACBAOBhKn - TCPOuFBzZQX/N3O9dm9P9iv - UIMoId== ) + www.example.com. IN HIP ( 2 4009D9BA7B1A74DF365639CC39F1D578 + AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIv + M4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy + 87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRG + Qb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48A + WkskmdHaVDP4BcelrTI3rMXdXF5D ) Example of a node with a HI, HIT and one RVS: - www.example.com IN HIP ( 2 2A20E0FF0FE8A52422D059FFFEA938A1 - AB3NzaC1kc3MAAACBAOBhKn - TCPOuFBzZQX/N3O9dm9P9iv - UIMoId== + www.example.com. IN HIP ( 2 4009D9BA7B1A74DF365639CC39F1D578 + AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIv + M4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy + 87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRG + Qb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48A + WkskmdHaVDP4BcelrTI3rMXdXF5D rvs.example.com ) Example of a node with a HI, HIT and two RVS: - www.example.com IN HIP ( 2 2A20E0FF0FE8A52422D059FFFEA938A1 - AB3NzaC1kc3MAAACBAOBhKn - TCPOuFBzZQX/N3O9dm9P9iv - UIMoId== + www.example.com. IN HIP ( 2 4009D9BA7B1A74DF365639CC39F1D578 + AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIv + M4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy + 87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRG + Qb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48A + WkskmdHaVDP4BcelrTI3rMXdXF5D rvs1.example.com rvs2.example.com ) 8. Security Considerations 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. @@ -554,46 +562,46 @@ solely on a HIT retrieved from DNS, but SHOULD rather use HI-based authentication. 8.3. DNSSEC In the absence of DNSSEC, the HIP RR is subject to the threats described in RFC 3833 [RFC3833]. 9. IANA Considerations - IANA should allocate one new RR type code for the HIP RR from the - standard RR type space. + IANA should allocate one new RR type code (TBD, 55?) for the HIP RR + from the standard RR type space. 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 IPSECKEY RR [RFC4025]. The presently defined values are shown here for reference: 0 is reserved 1 is RSA 2 is DSA 10. Acknowledgments 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 IPSECKEY RR [RFC4025] 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: Rob Austein, Hannu Flinck, Tom - Henderson, Olaf Kolkman, Miika Komu, Andrew McGregor, Erik Nordmark, - and Gabriel Montenegro. Some parts of this draft stem from - [I-D.ietf-hip-base]. + 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 [I-D.ietf-hip-base]. 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. 11. References