idnits 2.17.1 draft-henderson-hip-applications-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 277. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 13, 2005) is 7012 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '1') -- Possible downref: Normative reference to a draft: ref. '2' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Henderson 2 Internet-Draft The Boeing Company 3 Expires: August 14, 2005 February 13, 2005 5 Using HIP with Legacy Applications 6 draft-henderson-hip-applications-00 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 14, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 The Host Identity Protocol and architecture (HIP) proposes to add a 42 cryptographic name space for network stack names. From an 43 application viewpoint, HIP-enabled systems support a new address 44 family (e.g., AF_HOST), but it may be a long time until such 45 HIP-aware applications are widely deployed even if host systems are 46 upgraded. This informational document discusses implementation and 47 API issues relating to using HIP in situations in which the system is 48 HIP-aware but the applications are not. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Approaches for supporting legacy applications . . . . . . . . 5 55 3.1 Using IP addresses in applications . . . . . . . . . . . . 5 56 3.2 Using DNS . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.3 Connecting directly to a HIT . . . . . . . . . . . . . . . 7 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 61 Intellectual Property and Copyright Statements . . . . . . . . 9 63 1. Introduction 65 The Host Identity Protocol (HIP) [1] is an experimental effort in the 66 IETF and IRTF to study a new public-key-based name space for use as 67 host identifiers in Internet protocols. Fully deployed, the HIP 68 architecture will permit applications to explicitly request the 69 system to connect to another named host by expressing the name of the 70 host when the system call to connect is performed. However, there 71 will be a transition period during which systems become HIP-enabled 72 but applications are not. 74 When applications and systems are both HIP-aware, the coordination 75 between the application and the system can be straightforward. For 76 example, using the terminology of the widely used sockets API, the 77 application can issue a system call to connect to another host by 78 naming it explicitly, and the system can perform the necessary 79 name-to-address mapping to assign appropriate routable addresses to 80 the packets. To enable this, a new address family (e.g., AF_HOST) 81 could be defined, and additional API extensions could be defined 82 (such as allowing IP addresses to be passed in the system call, along 83 with the host name, as hints of where to initially try to reach the 84 host). 86 This draft does not define a native HIP API such as described above. 87 Rather, this draft is concerned with the scenario in which the 88 application is not HIP-aware and a traditional (sockets) API is used 89 by the application. To use HIP in such a situation, there are a few 90 basic possibilities: i) allow applications to use IP addresses as 91 before, and provide a mapping from IP address to host name (and back 92 to IP address) within the system, ii) take advantage of domain name 93 resolution to provide the application with either an alias for the 94 host identifier or (in the case of IPv6) the host identity tag (HIT) 95 itself, and iii) support the use of HITs directly (without prior DNS 96 resolution) in place of IPv6 addresses. This draft describes several 97 variations of the above strategies and suggests some pros and cons to 98 each approach. 100 2. Terminology 102 Referral: When the application passes what it believes to be an IP 103 address to another application instance on another host, within 104 its application data stream. An example is the FTP PORT command. 106 Resolver: The system function used by applications to resolve domain 107 names to IP addresses. 109 3. Approaches for supporting legacy applications 111 This section provides examples of how legacy applications, using 112 legacy APIs, can operate over a HIP-enabled system and use HIP. The 113 examples are organized by the name used by an application (or 114 application user) to name the peer system: an IP address, a domain 115 name, or a HIT. 117 3.1 Using IP addresses in applications 119 Consider the case in which an application issues a "connect(ip)" 120 system call to connect to a system named by address "ip", but for 121 which we would like to enable HIP to protect the communications. 122 Since the application or user does not (can not) in this case 123 indicate a desire to use HIP by using the standard sockets API, the 124 decision to invoke HIP must be done on the basis of policy. For 125 example, if an IPsec-like implementation of HIP is being used, a 126 policy may be entered into the security policy database that mandates 127 to use or try HIP based on a match on the source or destination IP 128 address, or other factors. 130 There are a number of ways that HIP could be used in such a scenario. 132 Manual configuration: 133 Pre-existing SAs may be available due to previous administrative 134 action. 136 Opportunistically: 137 The system could send an I1 to the Responder with an empty value 138 for Responder HIT. 140 Using DNS: 141 If the responder has host identities registered in the forward DNS 142 zone and has a PTR record in the reverse zone, the initiating 143 system could perform a reverse+forward lookup to learn the HIT 144 associated with the address. 146 These types of solutions have the benefit of naturally supporting 147 application-level referrals, since the applications always use IP 148 addresses. They have weaker security properties than full HIP, 149 however, because the binding between host identity and address is 150 weak. In fact, the semantics of the application's "connect(ip)" call 151 may be interpreted as "connect me to the system reachable at IP 152 address ip" but perhaps no stronger semantics than that. HIP can be 153 used in this case to provide perfect forward secrecy and 154 authentication, but not to strongly authenticate the peer at the 155 onset of communications. DNS, if trusted, may be able to provide 156 some additional initial authentication, but at a cost of initial 157 resolution latency. 159 3.2 Using DNS 161 In the previous section, it was pointed out that a HIP-enabled system 162 might make use of DNS to transparently fetch host identifiers prior 163 to the onset of communication. For applications that make use of 164 DNS, the name resolution process is another opportunity to use HIP. 165 If host identities are bound to domain names, with a trusted DNS, the 166 following are possible: 168 Return HIP LSIs instead of IP addresses: 169 The system resolver could be configured to return a Local Scope 170 Identifier (LSI) rather than an IP address, if HIP information is 171 available in the DNS that binds a particular domain name to a host 172 identity, and to otherwise return an IP address. The system can 173 then maintain a mapping between LSI and host identity and perform 174 the appropriate conversion in the transport layer and below. The 175 application uses the LSI as it would an IP address. 177 Locally use a HIP-specific domain name suffix: 178 One drawback to spoofing the DNS resolution is that some 179 applications actually may want to fetch IP addresses (e.g., 180 diagnostic applications such as ping). One way to provide finer 181 granularity on whether the resolver returns an IP address or an 182 LSI is to distinguish by the presence of a domain name suffix. 183 Specifically, if the application requests to resolve 184 "www.ietf.org.hip" (or some similar suffix), then the system 185 returns an LSI, while if the application requests to resolve 186 "www.ietf.org", IP address(es) are returned as usual. 188 If the LSI is non-routable, a couple of potential hazards arise. 189 First, applications that perform referrals may pass the LSI to 190 another system that has no system context to resolve the LSI back to 191 a host identity or an IP address. Note that these are the same type 192 of applications that will likely break if used over certain types of 193 NATs. Second, applications may cache the results of DNS queries for 194 a long time, and it may be hard for a HIP system to determine when to 195 perform garbage collection on the LSI bindings. 197 It may be possible for an LSI to be routable, but such a case may not 198 have the level of security in the binding to host identity that a HIT 199 has with the host identity. For example, a special IP address that 200 have some location invariance is the identifier-address discussed in 201 [2]. In general, LSIs considered to date for HIP have been 202 non-routable. 204 3.3 Connecting directly to a HIT 206 The previous two sections describe the use of IP addresses and and 207 LSIs as "handles" to a host identity. A third approach, for IPv6 208 applications, is to configure the application to connect directly to 209 a HIT (e.g., "connect(HIT)" as a socket call). Although more 210 cumbersome for human users (due to the flat HIT name space) than 211 using either IPv6 addresses or domain names, this scenario has 212 stronger security semantics, because the application is asking the 213 system to connect specifically to the named peer system. 215 It may be hard in this case for a system to distinguish between a HIT 216 and a routable IPv6 address. Elsewhere it has been proposed that 217 HITs be precluded (temporarily) from using highest-ordered bits that 218 correspond to IPv6 addresses, so that at least in the near term, a 219 system could differentiate between a HIT and an IPv6 address by 220 inspection. 222 Another challenge with this approach is in actually finding the IP 223 addresses to use, based on the HIT. Some type of HIT resolution 224 service would be needed in this case. 226 A third challenge of this approach is in supporting referrals to 227 possibly non-HIP-aware hosts. However, since most communications in 228 this case would likely be to other HIP-aware hosts (else the initial 229 connect() would fail), the problem may be instead if the peer host 230 supports HIP but is not able to perform HIT resolution for some 231 reason. 233 4. Security Considerations 235 To be completed. 237 5 References 239 [1] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-01 240 (work in progress), October 2004. 242 [2] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", 243 draft-ietf-multi6-l3shim-00 (work in progress), January 2005. 245 Author's Address 247 Tom Henderson 248 The Boeing Company 249 P.O. Box 3707 250 Seattle, WA 251 USA 253 EMail: thomas.r.henderson@boeing.com 255 Intellectual Property Statement 257 The IETF takes no position regarding the validity or scope of any 258 Intellectual Property Rights or other rights that might be claimed to 259 pertain to the implementation or use of the technology described in 260 this document or the extent to which any license under such rights 261 might or might not be available; nor does it represent that it has 262 made any independent effort to identify any such rights. Information 263 on the procedures with respect to rights in RFC documents can be 264 found in BCP 78 and BCP 79. 266 Copies of IPR disclosures made to the IETF Secretariat and any 267 assurances of licenses to be made available, or the result of an 268 attempt made to obtain a general license or permission for the use of 269 such proprietary rights by implementers or users of this 270 specification can be obtained from the IETF on-line IPR repository at 271 http://www.ietf.org/ipr. 273 The IETF invites any interested party to bring to its attention any 274 copyrights, patents or patent applications, or other proprietary 275 rights that may cover technology that may be required to implement 276 this standard. Please address the information to the IETF at 277 ietf-ipr@ietf.org. 279 Disclaimer of Validity 281 This document and the information contained herein are provided on an 282 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 283 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 284 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 285 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 286 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 287 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 289 Copyright Statement 291 Copyright (C) The Internet Society (2005). This document is subject 292 to the rights, licenses and restrictions contained in BCP 78, and 293 except as set forth therein, the authors retain all their rights. 295 Acknowledgment 297 Funding for the RFC Editor function is currently provided by the 298 Internet Society.