idnits 2.17.1 draft-ponomarev-hip-hit2ip-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2009) is 5401 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-ponomarev-hip-dns-locators-00 ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) == Outdated reference: A later version (-06) exists of draft-ahrenholz-hiprg-dht-03 == Outdated reference: A later version (-09) exists of draft-ietf-dnsop-as112-ops-01 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Host Identity Protocol O. Ponomarev 3 Internet-Draft A. Gurtov 4 Intended status: Experimental Helsinki Institute for Information 5 Expires: January 14, 2010 Technology HIIT 6 July 13, 2009 8 Embedding Host Identity Tags Data in DNS 9 draft-ponomarev-hip-hit2ip-04 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 14, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document proposes conventions to access and manage Host Identity 48 Tag (HIT) mappings using the Domain Name System (DNS) interface. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Domain Names for HIT Mappings . . . . . . . . . . . . . . . . 4 54 2.1. Preconfigured Domain . . . . . . . . . . . . . . . . . . . 4 55 2.2. Listing IP Addresses of the System . . . . . . . . . . . . 4 56 2.3. Listing Locators of the System in the Extended Format . . 4 57 2.4. Listing Host Names . . . . . . . . . . . . . . . . . . . . 5 58 2.5. Link to another domain . . . . . . . . . . . . . . . . . . 5 59 2.6. Managing the Records . . . . . . . . . . . . . . . . . . . 5 60 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Initial Deployment . . . . . . . . . . . . . . . . . . . . 6 62 3.2. Parallel Services . . . . . . . . . . . . . . . . . . . . 6 63 3.3. Two-level Mapping . . . . . . . . . . . . . . . . . . . . 7 64 3.4. Local Mapping . . . . . . . . . . . . . . . . . . . . . . 8 65 3.5. Link to Mapping Service . . . . . . . . . . . . . . . . . 9 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 One of the approaches to use legacy applications[RFC5338] with Host 77 Identity Protocol[RFC4423] is to use HIT as IPv6 address. The 78 application may receive them from the nameserver, store internally 79 and connect directly to a HIT. The HIP software would receive packet 80 with HIT as a destination IPv6 address without any additional 81 information about the current locator and therefore some HIT 82 resolution service is needed in this case. This document suggests 83 the DNS as a protocol to access such mapping databases in addition to 84 a local list of Host Identities and Distributed Hash Tables (DHT) 85 [I-D.ahrenholz-hiprg-dht]. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119[RFC2119]. 91 2. Domain Names for HIT Mappings 93 Domain Name System is well-known to systems administrators and there 94 is much experience with operations under high load. It also allows 95 dynamic modifications and has low overhead when compared to many 96 other protocols. It is used now, for example, to get IP address 97 reputations from various blacklists. 99 2.1. Preconfigured Domain 101 The systems using this method MUST have the same domain pre- 102 configured, for example hit-to-ip.example.net. If there are multiple 103 parallel services with their own domains, the systems MUST have at 104 least one of them in common to interoperate. 106 A HIT is represented as a sequence of nibbles separated by dots and 107 followed by the suffix similarly to IPv6 addresses in 108 ip6.arpa[RFC3596]. For example, the domain name corresponding to the 109 HIT 111 2001:10:1234:5678:9abc:def0:1234:5678 113 would be 115 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. 116 hit-to-ip.example.net 118 2.2. Listing IP Addresses of the System 120 The A/AAAA resource record types MAY be used to specify the IP/IPv6 121 addresses of the system. There MAY be multiple locators listed for a 122 HIT. 124 For example, the system with IP address 192.0.2.1 and IPv6 address 125 2001:DB8::1 would have the following records 127 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. 128 hit-to-ip.example.net. 129 1 IN A 192.0.2.1 130 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. 131 hit-to-ip.example.net. 132 1 IN AAAA 2001:DB8::1 134 2.3. Listing Locators of the System in the Extended Format 136 All the available locators of various types MAY be listed in a signle 137 record using extended format of HIP RR as in 138 draft-ponomarev-hip-dns-locators [I-D.ponomarev-hip-dns-locators]. 140 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. 141 hit-to-ip.example.net. 142 1 IN HIP 143 {2001:10:1234:5678:9abc:def0:1234:5678}{}{192.0.2.1,2001:DB8::1} 145 2.4. Listing Host Names 147 The PTR resource record types MAY be used to specify name of the host 148 using the Host Identity. 150 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. 151 hit-to-ip.example.net. 152 86400 IN PTR alpha.example.com. 154 2.5. Link to another domain 156 The CNAME resource record types MAY be used to specify another domain 157 to lookup the locators of the system. 159 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. 160 hit-to-ip.example.net. 161 86400 IN CNAME 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5. 162 4.3.2.1.0.1.0.0.1.0.0.2.hit-to-ip.domain.example. 164 2.6. Managing the Records 166 The system MAY send DNS UPDATE[RFC2136] to the server provided by SOA 167 MNAME field of the domain. The system MAY add or delete 168 A,AAAA,PTR,CNAME records for its own HIT representation. The update 169 MUST then originate from the corresponding HIT. If there are 170 multiple identities they should be modified separately. 172 The domain provided in SOA MNAME field of the preconfigured domain 173 MUST have Host Identity of the server stored in DNS, the IP addresses 174 MUST be listed in that domain using the suggested method and the 175 server MUST accept DNS UPDATE messages, which add or delete 176 A,AAAA,PTR,CNAME records for the HIT representation of the client 177 after successful HIP base exchange. The HIP base exchange serves to 178 authenticate the origin of the DNS UPDATE and server MUST refuse to 179 perform the changes if the update is not originating from the host 180 identity whose data is being updated. 182 3. Usage Scenarios 184 The DNS selected as an interface should help in the deployment. 185 There is vast number of resursive DNS resolvers available to the 186 clients, they can cache mapping information, for example. This 187 section contains ideas about different designs of the mapping 188 service. 190 3.1. Initial Deployment 192 Such global mapping service would be useful for the Host Identities 193 that are not published for any domain name. It can be started up 194 using the conventional DNS software with minor changes to 195 authenticate DNS updates with HIP. There is hit-to-ip.net zone 196 available for the experiments at the moment. According to the 197 measurements[ISC-TN-2008-1] BIND 9 is able to send 60,361 replies/ 198 second under update at 256 updates/sec over IXFR. The performance of 199 DDNS updates was only 93.46 updates/second as they are committed to 200 nonvolatile storage before the response is returned. The version of 201 BIND compiled without the file-system commits performed 471.70 202 updates/second. The performance of HIP implementations also limits 203 the capacity, but about active 100,000 users may be served assuming 1 204 hour average update interval, if the peak performance is 100 updates/ 205 second. Number of mappings that fits into the memory of a modern 206 server has to be studied. 208 The TTL of the records is selected by the clients. If a Host 209 Identity is used by a server with static IP addresses, its mappings 210 may have long TTLs as any changes are scheduled in advance. This 211 would allow the recursive resolvers to cache records of the 212 frequently accessed static servers. 214 Delegation of 1.0.0.1.0.0.2.ip6.arpa would allow reverse resolution 215 of HIT to a host name by any system without any changes. The host 216 name does not change often and such mapping may be updated only when 217 needed. 219 Although the service may be started with existing DNS software, it is 220 not optimal for such a usage pattern and another database engine 221 allowing higher update rate is needed. 223 3.2. Parallel Services 225 Although it is not desirable, there may be multiple independent 226 mapping services. I.e. the host updates its IP addresses only in 227 hit-to-ip.domain1.example, but has to look for IP addresses of an 228 unknown host in hit-to-ip.domain1.example, hit-to-ip.domain2.example 229 and hit-to-ip.domain3.example. This causes extra traffic due to 230 multiple lookups. 232 Another possibility is that the host updates its IP addresses in hit- 233 to-ip.domain1.example, hit-to-ip.domain2.example and hit-to- 234 ip.domain3.example, but chose only hit-to-ip.domain1.example to 235 lookup unknown hosts. This would cause growth of all three databases 236 with every new user and extra traffic due to multiple updates, but 237 provides redundancy 239 The delegation of domain for reverse mapping is unlikely in this case 240 and would probably be blackholed similar to reverse subdomains for 241 private-use netblocks [I-D.ietf-dnsop-as112-ops] 243 3.3. Two-level Mapping 245 The flat identifiers do not have administrative division as in usual 246 domain names and a single organization should serve all the 247 identifiers. Therefore it is desirable to reduce its workload at the 248 same time TTL of the records cannot be long to allow dynamic changes. 249 Two-level design might help to solve this contradiction. 251 The first level would contain only links (CNAME) to different second 252 level mapping providers. Such information does not change often and 253 can have long TTL. Furthermore in this case, it would be enough to 254 store in memory only HIT and an index of the second level provider 255 both in binary format. The second level mapping would contain 256 dynamic information about the current IP addresses. For example, 257 there may be the following records in the DNS: 259 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. 260 hit-to-ip.arpa. 261 86400 IN CNAME 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5. 262 4.3.2.1.0.1.0.0.1.0.0.2.hit-to-ip.domain.example. 264 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. 265 ip6.arpa. 266 86400 IN CNAME 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5. 267 4.3.2.1.0.1.0.0.1.0.0.2.hit-to-host.domain.example. 269 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. 270 hit-to-ip.domain.example. 271 1 IN A 192.0.2.1 273 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. 274 hit-to-ip.domain.example. 275 1 IN AAAA 2001:DB8::1 277 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. 278 hit-to-host.domain.example. 279 86400 IN PTR alpha.example.com. 281 The information about frequently accessed static hosts may be 282 available already at the first level. 284 3.4. Local Mapping 286 Such mapping does not have to be global. If the host has a domain 287 name with HIP and A/AAAA records, for example 289 alpha.example.com. 290 3600 IN HIP {2001:10:1234:5678:9abc:def0:1234:5678} 291 3600 IN A 192.0.2.1 292 3600 IN AAAA 2001:DB8::1 294 and a legacy application sends AAAA? query to its recursive 295 nameserver, the nameserver may reply with 2001:10:1234:5678:9abc: 296 def0:1234:5678 in AAAA data and add the following domain name (unless 297 it already exists): 299 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. 300 hit-to-ip.domain.example. 301 86400 IN CNAME alpha.example.com. 303 The application would send packets to 2001:10:1234:5678:9abc:def0: 304 1234:5678 and HIP software would be able to retrieve its current 305 location from the local hit-to-ip mapping. The nameserver may remove 306 the mapping sometimes, but it might be needed for a long time if the 307 application stores 2001:10:1234:5678:9abc:def0:1234:5678 internally. 308 The same technique may be used with Local Scope Identifiers for IPv4 309 legacy applications. 311 3.5. Link to Mapping Service 313 Some users can change the records for their domain manually, but do 314 not have DDNS updates. Then it would be usefull to publish data 315 (including full Host Identity) in the mapping service and put CNAME 316 for the domain name: 318 alpha.example.com. CNAME 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9. 319 8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2.hit-to-ip.domain.example. 321 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. 322 hit-to-ip.domain.example. 323 86400 IN HIP {2001:10:1234:5678:9abc:def0:1234:5678} 325 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. 326 hit-to-ip.domain.example. 327 1 IN A 192.0.2.1 329 8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2. 330 hit-to-ip.domain.example. 331 1 IN AAAA 2001:DB8::1 333 In this case, a legacy system would resolve the hostname to its IP 334 addresses and would reach its current location, a HIP hosts would 335 start HIP session. Any other dynamic DNS service may be used, if it 336 allows HIP resource records. 338 4. Security Considerations 340 SHA1 is used now as a hash function to get HITs, but the complexity 341 of an existing attack[SHA1-attack] is only 2**63. Since only HIT, 342 but not complete HI is used for lookups, SHA1 should be phased out, 343 for example, in favor of the SHA-2 variants. 345 The actions, when multiple hosts share the same identity and start to 346 constantly update their mappings, should be discussed. 348 5. IANA Considerations 350 This draft would require that the IANA delegates 351 1.0.0.1.0.0.2.IP6.ARPA subdomain and HIT-TO-IP.ARPA for the Host 352 Identity Protocol usage. 354 6. Acknowledgments 356 The authors would like to thank Tom Henderson and Miika Komu, who 357 provided comments and helped to improve this document. 359 7. References 361 7.1. Normative References 363 [I-D.ponomarev-hip-dns-locators] 364 Ponomarev, O., "Storing Host Locators in HIP Resource 365 Record", draft-ponomarev-hip-dns-locators-00 (work in 366 progress), July 2009. 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, March 1997. 371 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 372 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 373 RFC 2136, April 1997. 375 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 376 (HIP) Architecture", RFC 4423, May 2006. 378 [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host 379 Identity Protocol with Legacy Applications", RFC 5338, 380 September 2008. 382 7.2. Informative References 384 [I-D.ahrenholz-hiprg-dht] 385 Ahrenholz, J., "HIP DHT Interface", 386 draft-ahrenholz-hiprg-dht-03 (work in progress), 387 October 2008. 389 [I-D.ietf-dnsop-as112-ops] 390 Abley, J. and W. Maton, "AS112 Nameserver Operations", 391 draft-ietf-dnsop-as112-ops-01 (work in progress), 392 November 2008. 394 [ISC-TN-2008-1] 395 Reid, B., "BIND 9 performance while serving large zones 396 under update", February 2008, 397 . 399 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 400 "DNS Extensions to Support IP Version 6", RFC 3596, 401 October 2003. 403 [SHA1-attack] 404 Schneier, B., "New Cryptanalytic Results Against SHA-1", 405 August 2005, . 408 Authors' Addresses 410 Oleg Ponomarev 411 Helsinki Institute for Information Technology HIIT 412 PO Box 9800 413 TKK FIN-02015 414 Finland 416 Email: oleg.ponomarev@hiit.fi 418 Andrei Gurtov 419 Helsinki Institute for Information Technology HIIT 420 PO Box 9800 421 TKK FIN-02015 422 Finland 424 Email: gurtov@cs.helsinki.fi