idnits 2.17.1 draft-melen-hip-proxy-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 99: '...e HIP-proxy node MUST reside on the no...' RFC 2119 keyword, line 103: '... exchange. HIP-proxy node MAY also be...' RFC 2119 keyword, line 106: '...oing traffic, it MAY also function as ...' RFC 2119 keyword, line 116: '... The HIP-proxy MAY generate a Host I...' RFC 2119 keyword, line 120: '... Host identity MAY be triggered by D...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 20, 2009) is 5362 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5204 (Obsoleted by RFC 8004) ** Obsolete normative reference: RFC 5205 (Obsoleted by RFC 8005) ** Obsolete normative reference: RFC 5206 (Obsoleted by RFC 8046) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Melen 3 Internet-Draft J. Ylitalo 4 Intended status: Experimental P. Salmela 5 Expires: February 21, 2010 Ericsson Research NomadicLab 6 August 20, 2009 8 Host Identity Protocol-based Mobile Proxy 9 draft-melen-hip-proxy-02 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 February 21, 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 defines a HIP-proxy node that enables non-HIP host to 48 communicate with HIP host through a proxy node without requiring 49 changes to the non-HIP host. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. HIP-Proxy Architecture . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Assigning Host Identity to non-HIP host . . . . . . . . . 4 56 2.2. Registering Host Identity IP address mapping to RVS . . . 4 57 2.3. Registering Host Identity to DNS . . . . . . . . . . . . . 4 58 3. Parameters and packet formats . . . . . . . . . . . . . . . . 6 59 3.1. Proxy information parameter . . . . . . . . . . . . . . . 6 60 4. Packet processing . . . . . . . . . . . . . . . . . . . . . . 7 61 4.1. Opportunistic I1 . . . . . . . . . . . . . . . . . . . . . 7 62 4.1.1. Rendezvous node . . . . . . . . . . . . . . . . . . . 7 63 4.1.2. HIP-proxy or HIP-node . . . . . . . . . . . . . . . . 7 64 4.2. I1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.3. R1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.4. I2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.5. R2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.6. Data packets . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.6.1. Sending data over ESP SA . . . . . . . . . . . . . . . 8 70 4.6.2. Receiving data over ESP SA . . . . . . . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 74 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 The Host Identity Protocol (HIP) [RFC5201] has been designed to allow 80 hosts to preserve existing security associations and higher-layer 81 protocol sessions by defining host mobility and multihoming 82 mechanisms [RFC5206]. Specifically, a mobile or multihomed host that 83 changes its IP address, or acquires new addresses, can securely 84 notify its corresponding peers of the new address(es). Similarly, a 85 mobile HIP-aware host can update information about its current IP 86 address(es) by updating records in HIP Rendezvous Servers [RFC5204] 87 or other name services. 89 This draft describes HIP protocol extensions that allow a non-HIP 90 host to use the services of a HIP-aware proxy node and have 91 capabilities to communicate with a HIP host and to be mobile when 92 moving together with the HIP-proxy node. The HIP-proxy node 93 functions as a middle node that will encapsulate and decapsulate the 94 packets that are destined to a HIP host or to a non-HIP host behind 95 another HIP-proxy. The HIP-proxy will handle all the HIP signaling 96 on behalf of the non-HIP host and thus no modifications are required 97 to the connection end-points. 99 The HIP-proxy node MUST reside on the normal routing path of the 100 packets. HIP-proxy will capture and encapsulate/decapsulate packets 101 coming from or going to non-HIP host. The encapsulation procedure 102 will also apply encryption as specified by the HIP association that 103 is created during the HIP base exchange. HIP-proxy node MAY also be 104 aided by the DNS resolver in order to resolve the destination host's 105 host identity. While the HIP-proxy resides on the routing path of 106 the non-HIP host's outgoing traffic, it MAY also function as a DNS 107 proxy in which case all the DNS queries will pass through it. 109 2. HIP-Proxy Architecture 111 This section describes the extensions for the basic HIP [RFC5201] 112 that are required to support proxying of the traffic. 114 2.1. Assigning Host Identity to non-HIP host 116 The HIP-proxy MAY generate a Host Identity for each legacy host it 117 will represent in the network. In this case, the HI is bound to a 118 certain IP address. The HIP-proxy will create point-to-point tunnel 119 between the HIP-proxy and HIP end host. The generation of each new 120 Host identity MAY be triggered by DHCP or it MAY be generated 121 manually before hand. 123 Alternatively, the HIP-proxy MAY generate a Host Identity for a group 124 of network hosts. In this case, the HI is bound to a certain network 125 prefix. The HIP-proxy will create point-to-multi-point tunnel 126 between the HIP-proxy and HIP end-host. 128 The difference on whether the to create a single host identity to 129 represent multiple hosts or whether to create a one identity per IP 130 address is a trade-off between the whether the HIP-proxy needs to 131 carry the IP header between the HIP-proxy and the HIP-node or not. 133 2.2. Registering Host Identity IP address mapping to RVS 135 HIP-proxy MAY register the non-HIP aware host's IP address in to 136 rendezvous server for HIP hosts or proxies using the same rendezvous 137 system. The HIP host creates a opportunistic I1 packet (destination 138 HIT null) and includes the IP address of the non-HIP aware host as a 139 parameter to the I1 packet. HIP host's I1-packet is forwarded via 140 rendezvous system to the non-HIP host's proxy using the IP address of 141 the non-HIP host. When the I1 packet reaches the HIP-proxy that 142 registered the address that HIP-proxy will respond to the I1 packet 143 with R1 including the non-HIP aware host's IP address as a parameter 144 and the HI that represents non-HIP aware host. 146 The rendezvous system SHOULD verify that the HIP-proxy is authorized 147 to add the mapping between non HIP IP address and HI before accepting 148 the registration of the mapping. Rendezvous system SHOULD NOT add 149 any HI non-HIP IP mappings that it cannot verify to belong to that 150 HIP-proxy as this might cause unwanted behavior in the routing 151 system. 153 2.3. Registering Host Identity to DNS 155 The HIP-proxy MAY register the Host Identity (HI) resource record in 156 to the DNS as defined in the [RFC5205]. The HIP-proxy will associate 157 the HI with the FQDN of the non-HIP host. When the HI is resolved 158 from the DNS the resolving host will get the HI and address of the 159 host or HI and address of the rendezvous server of the HIP-proxy 160 depending on the local configuration policy. 162 3. Parameters and packet formats 164 In this section we define the additional HIP parameters needed to 165 carry the non-HIP host information between the two proxies or proxy 166 or HIP node. 168 3.1. Proxy information parameter 170 The Proxy Information (PINFO) parameter is used to carry the IPv4 or 171 IPv6 address the non-HIP node is using. Thus, the parameter will 172 have different type value depending on whether the parameter is 173 carrying the information of the initiator proxy's network or 174 information of the responder HIP-proxy's network. 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Type | Length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Reserved | Prefix length | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | | 184 | Prefix | 185 | | 186 | | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Type [ TBD by IANA: 190 PINFO_INITIATOR: 989 = 191 (2^9 + ... + 2^6 + 2^4 + ... + 2^2 + 2^0) 192 PINFO_RESPONDER: 991 = 193 (2^9 + ... + 2^6 + 2^4 + ... + 2^0) 194 ] 195 Length 20 196 Prefix Length Length of the prefix or length of netmask 197 Prefix an IPv6 prefix or an IPv4 address in "IPv4-Mapped 198 IPv6 address" format 200 4. Packet processing 202 4.1. Opportunistic I1 204 4.1.1. Rendezvous node 206 The rendezvous node parses the PINFO_RESPONDER parameter and searches 207 all the registered HIP-proxy client contexts through for an prefix 208 that was in the received PINFO_RESPONDER parameter. 210 4.1.2. HIP-proxy or HIP-node 212 The responder verifies the I1 as specified in the [RFC5201]. As a 213 additional step the responder MUST verify that the prefix included in 214 to the PINFO_RESPONDER parameter of I1 packet contains a prefix that 215 belongs some Host Identity which the host owns 217 4.2. I1 219 The responder verifies the I1 as specified in the [RFC5201]. As a 220 additional step the responder MAY verify that the prefix included in 221 to the PINFO_RESPONDER parameter of I1 packet contains a prefix that 222 belongs to the host identity represented by the destination HIT field 223 in the HIP protocol header. 225 4.3. R1 227 The initiator verifies the R1 as specified in the [RFC5201]. As a 228 additional step the initiator MUST verify that the prefix included in 229 to the PINFO_RESPONDER parameter of R1 packet contains a prefix that 230 it sent out in the PINFO of the I1 packet. 232 The initiator SHOULD first try to find the right HIP association 233 using the responders HIT or HI. If previous check returns empty HIP 234 association, then the initiator SHOULD check if it has sent any 235 opportunistic I1s and if any of those contains a matching prefix to 236 the prefix in PINFO_RESPONDER parameter in received R1 packet. 238 After parsing and verification of the R1 packet the initiator will 239 add mapping between the HI and the prefix provided by the 240 PINFO_RESPONDER in to the HIP association context. 242 4.4. I2 244 The responder verifies the I2 as specified in the [RFC5201]. As a 245 additional step the responder MUST parse the prefix included in to 246 the PINFO_INITIATOR parameter of I2 packet and add a mapping between 247 the HI and prefix in to the HIP association context. 249 4.5. R2 251 The initiator verifies the R2 as specified in the [RFC5201]. No 252 additional information is included in to the R2 message. 254 4.6. Data packets 256 4.6.1. Sending data over ESP SA 258 When receiving data packets from non-HIP node that are destined to a 259 host that is either HIP or another HIP-proxy node the HIP-proxy will 260 capture the packet and remove the IP header and send it through the 261 ESP SA. 263 4.6.2. Receiving data over ESP SA 265 When receiving data packets from ESP SA the HIP or HIP-proxy node 266 will reconstruct the original IP header and send it back to IP stack 267 for further processing. 269 5. Security Considerations 271 Address theft by registering a invalid non-HIP IP address HI mapping. 272 The Rendezvous node should verify that the IP address claimed by the 273 HIP-proxy is really residing behind HIP-proxy. 275 6. IANA Considerations 276 7. Acknowledgments 278 A number of people have contributed to the text and ideas. The list 279 of these people include Pekka Nikander, Petri Jokela, Raimo 280 Vuopionpera, and Jari Arkko. Our apologies to anyone whose name is 281 missing. 283 8. Normative References 285 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 286 "Host Identity Protocol", RFC 5201, April 2008. 288 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 289 Rendezvous Extension", RFC 5204, April 2008. 291 [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol 292 (HIP) Domain Name System (DNS) Extensions", RFC 5205, 293 April 2008. 295 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 296 Host Mobility and Multihoming with the Host Identity 297 Protocol", RFC 5206, April 2008. 299 Authors' Addresses 301 Jan Melen 302 Ericsson Research NomadicLab 303 JORVAS FIN-02420 304 FINLAND 306 Phone: +358 9 299 1 307 Email: jan.melen@nomadiclab.com 309 Jukka Ylitalo 310 Ericsson Research NomadicLab 311 JORVAS FIN-02420 312 FINLAND 314 Phone: +358 9 299 1 315 Email: jukka.ylitalo@nomadiclab.com 317 Patrik Salmela 318 Ericsson Research NomadicLab 319 JORVAS FIN-02420 320 FINLAND 322 Phone: +358 9 299 1 323 Email: patrik.salmela@nomadiclab.com