idnits 2.17.1 draft-ietf-hip-reload-instance-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 11, 2013) is 3840 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4843 (Obsoleted by RFC 7343) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6253 (Obsoleted by RFC 8002) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group A. Keranen 3 Internet-Draft G. Camarillo 4 Intended status: Experimental J. Maenpaa 5 Expires: April 14, 2014 Ericsson 6 October 11, 2013 8 Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) 9 Instance Specification for REsource LOcation And Discovery (RELOAD) 10 draft-ietf-hip-reload-instance-10 12 Abstract 14 This document is the Host Identity Protocol-Based Overlay Networking 15 Environment (HIP BONE) instance specification for the REsource 16 LOcation And Discovery (RELOAD) protocol. The document provides the 17 details needed to build a RELOAD-based overlay that uses HIP. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 14, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Node ID Generation . . . . . . . . . . . . . . . . . . . . . 3 57 5. Mapping between Protocol Primitives and HIP Messages . . . . 3 58 5.1. Forwarding Header . . . . . . . . . . . . . . . . . . . . 4 59 5.2. Security Block . . . . . . . . . . . . . . . . . . . . . 4 60 5.3. Replaced RELOAD Messages . . . . . . . . . . . . . . . . 5 61 6. Securing Communication . . . . . . . . . . . . . . . . . . . 5 62 7. Routing HIP Messages via the Overlay . . . . . . . . . . . . 6 63 8. Enrollment and Bootstrapping . . . . . . . . . . . . . . . . 6 64 9. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 7 65 10. RELOAD Overlay Configuration Document Extension . . . . . . . 7 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 14.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 14.2. Informational References . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The Host Identify Protocol-Based Overlay Networking Environment (HIP 77 BONE) specification [RFC6079] provides a high-level framework for 78 building HIP-based [RFC5201] overlays. The HIP BONE framework leaves 79 the specification of the details on how to combine a particular peer 80 protocol with HIP to build an overlay up to documents referred to as 81 HIP BONE instance specifications. As discussed in [RFC6079], a HIP 82 BONE instance specification needs to define, minimally: 84 o the peer protocol to be used. 86 o what kind of Node IDs are used and how they are derived. 88 o which peer protocol primitives trigger HIP messages. 90 o how the overlay identifier is generated. 92 This document addresses all the previous items and provides 93 additional details needed to build RELOAD-based HIP BONEs, referred 94 to here as RELOAD HIP BONEs. The details on how different RELOAD 95 modules would be integrated to a HIP implementation and what kind of 96 APIs are used between them are left as implementation details or to 97 be defined by other documents. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 In addition, this document uses the terms defined in [RFC5201], 105 [RFC6079], [RFC6028], and [I-D.ietf-p2psip-base]. 107 3. Peer Protocol 109 The peer protocol to be used is REsource LOcation And Discovery 110 (RELOAD) [I-D.ietf-p2psip-base]. When used with RELOAD, HIP replaces 111 the RELOAD's Forwarding and Link Management Layer (described in 112 Section 6.5 of [I-D.ietf-p2psip-base]). 114 4. Node ID Generation 116 This document specifies two modes for generating Node and Resource 117 IDs. Which mode is used in an actual overlay is defined by the 118 overlay configuration. Both of the modes are based on 16-byte ID 119 mode of RELOAD, and hence only 16-byte RELOAD Node and Resource IDs 120 MUST be used in a RELOAD HIP BONE. 122 HIP uses 128-bit Overlay Routable Cryptographic Hash Identifiers 123 (ORCHIDs) [RFC4843] as identifiers. In a RELOAD HIP BONE a peer's 124 ORCHID can be used as such as a RELOAD Node ID (the "ORCHID" mode). 125 In this mode all the RELOAD IDs, including Resource IDs, are prefixed 126 with the ORCHID prefix and the lower 100 bits of the IDs defined by 127 RELOAD usage documents are used after the prefix. 129 In the other Node ID mode, namely "RELOAD", all 128 bits are 130 generated as defined in [I-D.ietf-p2psip-base]. This results in a 131 larger usable address space than using the ORCHID mode, but the 132 resulting Node IDs cannot be used with legacy applications and APIs, 133 as discussed in Section 5.1 of [RFC6079]. 135 5. Mapping between Protocol Primitives and HIP Messages 136 RELOAD HIP BONE replaces the RELOAD protocol primitives taking care 137 of connection establishment with the HIP base exchange, whereas the 138 rest of the RELOAD messages are conveyed within HIP messages. The 139 Forwarding and Link Management Layer functionality of RELOAD, 140 including all the NAT traversal functionality, is replaced by HIP, 141 existing extensions of HIP, and the extensions defined in this 142 document. 144 The standard RELOAD messages consist of three parts: Forwarding 145 Header, Message Contents and the Security Block. When RELOAD 146 messages are sent in a RELOAD HIP BONE overlay, the RELOAD Message 147 Contents are used as such within HIP DATA [RFC6078] messages, but the 148 functionality of the Forwarding Header and Security Block are 149 replaced with HIP header, HIP Destination and Via lists [RFC6028], 150 and CERT [RFC6253], TRANSACTION_ID [RFC6078], OVERLAY_ID and 151 OVERLAY_TTL [RFC6079] parameters, as defined in the following 152 sections. 154 5.1. Forwarding Header 156 The RELOAD Forwarding Header is used for forwarding messages between 157 peers and to their final destination. The Forwarding Header's 158 overlay field value MUST be used as such in an OVERLAY_ID parameter 159 and the transaction_id field in a TRANSACTION_ID parameter. That is, 160 all RELOAD HIP BONE messages MUST contain these parameters and the 161 length of the OVERLAY_ID parameter's identifier field is 4 and the 162 length of the TRANSACTION_ID parameter is 8 octets. HIP Destination 163 and Via lists are used for the same purpose as the destination_list 164 and via_list in the Forwarding Header, with the exception that all 165 Resource IDs MUST be of the same length as Node IDs and compressed 166 IDs MUST NOT be used. The TTL value in the OVERLAY_TTL parameter is 167 used like the ttl field in the Forwarding Header. 169 The functionality of the fragment and length fields are provided by 170 the HIP headers. The relo_token, version, and max_response_length 171 are not needed with HIP and options field, if needed eventually for 172 some extensions, can be replaced with additional HIP parameters. 174 5.2. Security Block 176 The RELOAD Security Block contains certificates and digital 177 signatures of the message. All the HIP DATA messages are digitally 178 signed by the originator of the message and contain the HOST_ID 179 parameter with the identifier that can be used for verifying the 180 signature. Certificates are delivered in a HIP CERT parameter as 181 defined in [RFC6253] or stored to the overlay using the RELOAD 182 Certificate Storage Usage. 184 Note that when the RELOAD mode for Node ID generation is used, the 185 certificate certifying that a host is allowed to use a certain Node 186 ID MUST contain host's Node ID instead of HIT in the "Subject 187 Alternative Name" of the certificate as described in Section 11.3 of 188 [I-D.ietf-p2psip-base] while the "Subject" field contains the HIT 189 calculated from the Host Identity. 191 5.3. Replaced RELOAD Messages 193 The Attach procedure in RELOAD establishes a connection between two 194 peers. This procedure is performed using the AttachReq and AttachAns 195 messages. When HIP is used, the Attach procedure is performed by 196 using a HIP base exchange. That is, peers send HIP I1 messages 197 instead of RELOAD AttachReq messages. This behavior replaces the one 198 described in Section 6.5 of [I-D.ietf-p2psip-base]. 200 The AppAttach procedure in RELOAD is used for creating a connection 201 for other applications than RELOAD. Also the AppAttach procedure is 202 replaced with HIP base exchange and, after the base exchange, peers 203 can exchange any application layer data using the normal transport 204 layer ports over the NAT traversing IPsec connection. 206 This specification does not support flooding of configuration files, 207 so ConfigUpdate requests and responses (Section 6.5.4 of 208 [I-D.ietf-p2psip-base]) MUST NOT be sent in the overlay. RELOAD Ping 209 messages (Section 6.5.3 of [I-D.ietf-p2psip-base]) MAY be used. 211 For all other RELOAD messages the Message Contents are used as such 212 within HIP DATA messages. 214 6. Securing Communication 216 RELOAD uses TLS [RFC5246] connections for securing the hop-by-hop 217 messaging and certificates and signatures for providing integrity 218 protection for the overlay messages and for the data stored in the 219 overlay. 221 With a RELOAD HIP BONE, instead of using TLS connections as defined 222 in [I-D.ietf-p2psip-base], all HIP overlay messages MUST be sent 223 using encrypted connections [RFC6261]. 225 The data objects stored in the RELOAD HIP BONE overlay are signed and 226 the signatures are stored as defined in [I-D.ietf-p2psip-base] with 227 the exception that SignerIdentity is carried in the HIP DATA 228 message's HOST_ID parameter instead of using the RELOAD 229 SecurityBlock. Where certificates are needed, they are sent using 230 the HIP CERT parameter. 232 7. Routing HIP Messages via the Overlay 234 If a host has no valid locator for the receiver of a new HIP packet, 235 and the receiver is part of a RELOAD HIP BONE overlay the host is 236 participating in, the host can send the HIP packet to the receiver 237 using the overlay routing. 239 When sending a HIP packet via the overlay, the host MUST add an empty 240 ROUTE_VIA parameter [RFC6028] to the packet with the SYMMETRIC and 241 MUST_FOLLOW flags set and an OVERLAY_ID parameter containing the 242 identifier of the right overlay network. The host consults the 243 RELOAD Topology Plugin for the next hop and sends the HIP packet to 244 that host. 246 An intermediate host receiving a HIP packet with the OVERLAY_ID 247 parameter checks if it is participating in that overlay, and SHOULD 248 drop packets sent to unknown overlays. If the host is not the final 249 destination of the packet (i.e., the Receiver HIT in the HIP header 250 does not match to any of its HITs), it checks if the packet contains 251 a ROUTE_DST parameter. Such packets are forwarded to the next hop as 252 specified in [RFC6028]. If the packet does not contain a ROUTE_DST 253 parameter, the host finds the next hop from the RELOAD Topology 254 Plugin and forwards the packet there. As specified in [RFC6028], the 255 host adds the HIT it uses on the HIP association with the next hop 256 host to the end of the ROUTE_VIA parameter, if present. 258 When the final destination host receives the HIP packet, the host 259 processes it as specified in [RFC5201] and in case of HIP DATA 260 packet, the contents are processed as specified in 261 [I-D.ietf-p2psip-base]. If the HIP packet generates a response, the 262 response is routed back on the same path using the ROUTE_DST 263 parameter as specified in [RFC6028]. 265 8. Enrollment and Bootstrapping 267 The RELOAD HIP BONE instance uses the enrollment and bootstrap 268 procedure defined by RELOAD [I-D.ietf-p2psip-base] with the 269 exceptions listed below. 271 o In RELOAD, a node wishing to enroll in an overlay starts with 272 obtaining a configuration document as explained in 273 [I-D.ietf-p2psip-base]. This specification extends the RELOAD 274 overlay configuration document as defined in Section 10. 276 o The X.509 certificates used by the RELOAD HIP BONE instance are 277 similar to those of RELOAD except that they contain HITs instead 278 of RELOAD URIs. The HITs are included in the SubjectAltName field 279 of the certificate as described in [RFC6253]. 281 o When contacting a bootstrap node, instead of forming a DTLS or TLS 282 connection, the host MUST perform a HIP base exchange with the 283 bootstrap node. The base exchange MAY be performed using a HIP 284 rendezvous or relay server. 286 9. NAT Traversal 288 RELOAD relies on the Forwarding and Link Management Layer providing 289 NAT traversal capabilities. Thus, the RELOAD HIP BONE instance 290 implementations MUST implement some reliable NAT traversal mechanism. 291 To maximize interoperability, all implementations SHOULD implement at 292 least [RFC5770]. 294 HIP relay servers are not necessarily needed with this HIP BONE 295 instance since the overlay network can be used for relaying the Base 296 Exchange and further HIP signaling can be done directly between the 297 peers. However, if it is possible that a bootstrap peer is behind a 298 NAT, it MUST register with a HIP relay so that there is a reliable 299 way to connect to it. 301 10. RELOAD Overlay Configuration Document Extension 303 This document modifies the bootstrap-node element of the RELOAD 304 overlay configuration document. The modified bootstrap-node element 305 contains the following attributes: 307 address: The locator of the bootstrap node. 309 port: The HIP port of the bootstrap node. 311 hit: The HIT of the bootstrap node. 313 If the bootstrap-node element does not contain a HIT, the 314 opportunistic mode (as specified in [RFC5201]) SHOULD be used for 315 contacting the bootstrap node. If the element does not contain a 316 port number, the bootstrap node SHOULD be contacted by starting the 317 base exchange as defined in [RFC5201]. Otherwise, the base exchange 318 MUST be started UDP-encapsulated as defined in [RFC5770] using the 319 given port as the destination port number. 321 A RELOAD HIP BONE overlay MUST use Overlay Link Protocol type "HIP" 322 in the configuration document's overlay-link-protocol element. The 323 enrolling node MUST check the overlay-link-protocol element and 324 proceed with procedures defined in this document only if "HIP" link 325 type is found. 327 This document also adds a new element inside the configuration 328 element that defines which mode (see Section 4) is used for 329 generating the Node and Resource IDs. The name of the element is 330 "hipbone-id-mode" and the content is the identifier of the mode: 331 "ORCHID" for the ORCHID prefixed IDs and "RELOAD" for the IDs that 332 use the whole 128 bits as defined by the RELOAD specification. The 333 NodeIdLength MUST be set to 16 in the configuration document and the 334 16 bytes are used, depending on the generation mode, as defined in 335 Section 4. 337 11. Security Considerations 339 The security considerations of RELOAD (Section 13 of 340 [I-D.ietf-p2psip-base]), with the exception of TLS specific features, 341 apply also to RELOAD HIP BONE instances. 343 Limiting the Node ID and Resource ID space into 128 bits (or 100 bits 344 with ORCHID prefixes) results in a higher probability for ID 345 collisions, both unintentional and intentional, than using larger 346 address spaces. 348 12. IANA Considerations 350 This section is to be interpreted according to [RFC5226]. 352 IANA is requested to update the "Overlay Link Protocol" registry 353 [I-D.ietf-p2psip-base] by assigning new Overlay Link Protocol type 354 "HIP" (see Section 10). 356 13. Acknowledgements 358 Tom Henderson, Spencer Dawkins, and Christer Holmberg have provided 359 valuable reviews and comments on the draft. 361 14. References 363 14.1. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, March 1997. 368 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 369 for Overlay Routable Cryptographic Hash Identifiers 370 (ORCHID)", RFC 4843, April 2007. 372 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 373 "Host Identity Protocol", RFC 5201, April 2008. 375 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 376 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 377 May 2008. 379 [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 380 Keranen, "Basic Host Identity Protocol (HIP) Extensions 381 for Traversal of Network Address Translators", RFC 5770, 382 April 2010. 384 [RFC6028] Camarillo, G. and A. Keranen, "Host Identity Protocol 385 (HIP) Multi-Hop Routing Extension", RFC 6028, October 386 2010. 388 [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) 389 Immediate Carriage and Conveyance of Upper-Layer Protocol 390 Signaling (HICCUPS)", RFC 6078, January 2011. 392 [RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., 393 and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) 394 Based Overlay Networking Environment (BONE)", RFC 6079, 395 January 2011. 397 [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol 398 Certificates", RFC 6253, May 2011. 400 [RFC6261] Keranen, A., "Encrypted Signaling Transport Modes for the 401 Host Identity Protocol", RFC 6261, May 2011. 403 [I-D.ietf-p2psip-base] 404 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 405 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 406 Base Protocol", draft-ietf-p2psip-base-26 (work in 407 progress), February 2013. 409 14.2. Informational References 411 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 412 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 414 Authors' Addresses 416 Ari Keranen 417 Ericsson 418 Hirsalantie 11 419 02420 Jorvas 420 Finland 422 Email: Ari.Keranen@ericsson.com 423 Gonzalo Camarillo 424 Ericsson 425 Hirsalantie 11 426 Jorvas 02420 427 Finland 429 Email: Gonzalo.Camarillo@ericsson.com 431 Jouni Maenpaa 432 Ericsson 433 Hirsalantie 11 434 Jorvas 02420 435 Finland 437 Email: Jouni.Maenpaa@ericsson.com