idnits 2.17.1 draft-ietf-hip-reload-instance-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- 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 (January 26, 2010) is 5204 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) == Outdated reference: A later version (-07) exists of draft-ietf-hip-bone-04 == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-06 == Outdated reference: A later version (-03) exists of draft-ietf-hip-via-00 == Outdated reference: A later version (-05) exists of draft-ietf-hip-hiccups-01 == Outdated reference: A later version (-12) exists of draft-ietf-hip-cert-02 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 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: July 30, 2010 Ericsson 6 January 26, 2010 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-00.txt 12 Abstract 14 This document specifies the HIP BONE instance specification for 15 RELOAD. It provides the details needed to build a RELOAD-based 16 overlay that uses HIP. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on July 30, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Peer ID Generation . . . . . . . . . . . . . . . . . . . . . . 3 62 5. Mapping between Protocol Primitives and HIP Messages . . . . . 4 63 5.1. Forwarding Header . . . . . . . . . . . . . . . . . . . . . 4 64 5.2. Security Block . . . . . . . . . . . . . . . . . . . . . . 4 65 5.3. Replaced RELOAD Messages . . . . . . . . . . . . . . . . . 5 66 6. Securing Communication . . . . . . . . . . . . . . . . . . . . 5 67 7. Routing HIP Messages via the Overlay . . . . . . . . . . . . . 6 68 8. Enrollment and Bootstrapping . . . . . . . . . . . . . . . . . 6 69 9. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 10. RELOAD Overlay Configuration Document Extension . . . . . . . . 7 71 11. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 72 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 73 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 13.1. Normative References . . . . . . . . . . . . . . . . . . . 8 75 13.2. Informational References . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 The HIP BONE (Host Identify Protocol-Based Overlay Networking 81 Environment) specification [I-D.ietf-hip-bone] provides a high-level 82 framework for building HIP-based [RFC5201] overlays. The HIP BONE 83 framework leaves the specification of the details on how to combine a 84 particular peer protocol with HIP to build an overlay up to documents 85 referred to as HIP BONE instance specifications. As discussed in 86 [I-D.ietf-hip-bone], a HIP BONE instance specification needs to 87 define, minimally: 89 o the peer protocol to be used. 90 o what kind of Peer IDs are used and how they are derived. 91 o which peer protocol primitives trigger HIP messages. 92 o how the overlay identifier is generated. 94 This document addresses all the previous items and provides 95 additional details needed to built RELOAD-based HIP BONEs. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 3. Peer Protocol 105 The peer protocol to be used is RELOAD, which is specified in 106 [I-D.ietf-p2psip-base]. When used with RELOAD, HIP replaces the 107 RELOAD's Forwarding and Link Management Layer (described in Section 108 5.5. of [I-D.ietf-p2psip-base]. 110 4. Peer ID Generation 112 This document specifies two modes for generating Peer IDs. Which 113 mode is used in an actual overlay is defined by the overlay 114 configuration. 116 RELOAD uses 128-bit peer IDs called Node IDs. Since HIP uses 128-bit 117 ORCHIDs [RFC4843], a peer's ORCHID can be used as such as a RELOAD 118 Node ID (the "ORCHID" mode). In this mode, also all the RELOAD 119 Resource IDs are prefixed with ORCHID prefix and the lower 100 bits 120 of the IDs, as defined by RELOAD usage documents, are used after the 121 prefix. 123 In the other Peer ID mode, namely "RELOAD", all 128 bits are 124 generated as defined in [I-D.ietf-p2psip-base] resulting in a larger 125 usable address space. 127 5. Mapping between Protocol Primitives and HIP Messages 129 RELOAD HIP BONE replaces the RELOAD protocol primitives taking care 130 of connection establishment with the HIP base exchange, where as the 131 rest of the RELOAD messages are conveyed within HIP messages. 133 The standard RELOAD messages consist of three parts: Forwarding 134 Header, Message Contents and the Security Block. When RELOAD 135 messages are sent in a RELOAD HIP BONE overlay, the RELOAD Message 136 Contents are used as such within HIP DATA [I-D.ietf-hip-hiccups] 137 messages, but the functionality of the Forwarding Header and Security 138 Block are replaced with HIP header, HIP VIA lists [I-D.ietf-hip-via], 139 and CERT [I-D.ietf-hip-cert], TRANSACTION_ID, OVERLAY_ID and 140 OVERLAY_TTL [I-D.ietf-hip-bone] parameters. 142 5.1. Forwarding Header 144 The RELOAD Forwarding Header is used for forwarding messages between 145 peers and to their final destination. The Forwarding Header's 146 overlay field's value MUST be used as such in an OVERLAY_ID parameter 147 and the transaction_id field in a TRANSACTION_ID parameter. That is, 148 all RELOAD HIP BONE messages MUST contain these parameters and the 149 length of the OVERLAY_ID parameter's identifier field is 4 and the 150 length of the TRANSACTION_ID's identifier 8 octets. HIP VIA lists 151 are used for the same purpose as the destination_list and via_list in 152 the Forwarding Header, with the exception that all resource IDs MUST 153 be of the same length as node IDs and compressed IDs MUST NOT be 154 used. The TTL value in the OVERLAY_TTL parameter is used like the 155 ttl field in the Forwarding Header. 157 The functionality of the fragment and length fields are provided by 158 the HIP headers. The relo_token, version, and max_res_len are not 159 needed with HIP and options field, if needed eventually for some 160 extensions, can be replaced with additional HIP parameters. 162 5.2. Security Block 164 The RELOAD Security Block contains certificates and digital 165 signatures of the message. All the HIP DATA messages are digitally 166 signed by the originator of the message and contain the HOST_ID 167 parameter with the identifier that can be used for verifying the 168 signature. Certificates are delivered in a HIP CERT parameter as 169 defined in [I-D.ietf-hip-cert] or stored to the overlay using the 170 RELOAD Certificate Storage Usage. 172 5.3. Replaced RELOAD Messages 174 The Attach procedure in RELOAD establishes a connection between two 175 peers. This procedure is performed using the AttachReq and AttachAns 176 messages. When HIP is used, the Attach procedure is performed by 177 using a HIP base exchange. That is, peers send HIP I1 messages 178 instead of RELOAD AttachReq or AppAttach messages. The RELOAD 179 AttachLite procedure is used for the same purpose as the Attach 180 procedure in scenarios with no NATs. When HIP is used, the 181 AttachLite procedure is also performed by using a HIP base exchange. 182 That is, peers send HIP I1 messages instead of RELOAD AttachLiteReq 183 messages. This behavior replaces the one described in Section 5.5. 184 of [I-D.ietf-p2psip-base]. 186 The AppAttach procedure in RELOAD is used for creating a connection 187 for other applications than RELOAD. Also the AppAttach procedure is 188 replaced with HIP base exchange and after the base exchange peers can 189 exchange any application layer data using the normal transport layer 190 ports over the NAT traversing IPsec connection. 192 This specification does not support flooding of configuration files, 193 so Config_Update requests and responses (Section 5.5.6. of 194 [I-D.ietf-p2psip-base]) MUST NOT be sent in the overlay. RELOAD Ping 195 messages (Section 5.5.5 of [I-D.ietf-p2psip-base]) MAY be used. 197 For all other RELOAD messages the Message Contents are used as such 198 within DATA messages. 200 6. Securing Communication 202 RELOAD uses TLS [RFC5246] connections for securing the hop-by-hop 203 messaging and certificates and signing for providing integrity 204 protection for the overlay messages and for the data stored in the 205 overlay. 207 With a RELOAD HIP BONE, instead of using TLS connections as defined 208 in [I-D.ietf-p2psip-base], all HIP overlay messages SHOULD be either 209 sent using encrypted connections (such as IPsec ESP tunnel between 210 two peers) or the contents of the messages SHOULD be in an ENCRYPTED 211 parameter (see Section 5.2.15 of [RFC5201]). Use of encrypted 212 connections is RECOMMENDED since that provides confidentiality also 213 for the HIP headers. 215 The data objects stored in the RELOAD HIP BONE overlay are signed and 216 the signatures are stored as defined in [I-D.ietf-p2psip-base] with 217 the exception that SignerIdentity is carried in the HIP DATA 218 message's HOST_ID parameter instead of using the RELOAD 219 SecurityBlock. If certificates are needed, they are sent using the 220 CERT parameter. 222 7. Routing HIP Messages via the Overlay 224 If a host has no valid locator for the receiver of a new HIP packet, 225 and the receiver is part of a RELOAD HIP BONE overlay the host is 226 participating in, the host can send the HIP packet to the receiver 227 using the overlay routing. 229 When sending a HIP packet via the overlay, the host MUST add an empty 230 ROUTE_VIA parameter [I-D.ietf-hip-via] to the packet with the 231 SYMMETRIC flag set and an OVERLAY_ID parameter containing the 232 identifier of the right overlay network. The host consults the 233 RELOAD Topology Plugin for the next hop and sends the HIP packet to 234 that host. 236 An intermediate host receiving a HIP packet with the OVERLAY_ID 237 parameter checks if it is participating in that overlay, and SHOULD 238 drop packets sent to unknown overlays. If the host is not the final 239 destination of the packet (i.e., the HIP header's receiver's HIT does 240 not match to any of its HITs), it checks if the packet contains a 241 ROUTE_DST parameter. Such packets are forwarded to the next hop as 242 specified in [I-D.ietf-hip-via]. Otherwise, the host finds the next 243 hop from the RELOAD Topology Plugin and forwards the packet there. 244 As specified in [I-D.ietf-hip-via], the host adds the HIT it uses on 245 the HIP association with the next hop host to the end of the 246 ROUTE_VIA parameter, if present. 248 When the final destination host receives the HIP packet, the host 249 processes it as specified in [RFC5201]. If the HIP packet generates 250 a response, the response is routed back on the same path using the 251 ROUTE_DST parameter as specified in [I-D.ietf-hip-via]. 253 8. Enrollment and Bootstrapping 255 The RELOAD HIP BONE instance uses the enrollment and bootstrap 256 procedure defined by RELOAD [I-D.ietf-p2psip-base] with the 257 exceptions listed below. 259 o In RELOAD, a node wishing to enroll in an overlay starts with a 260 discovery process to find an enrollment server as explained in 261 [I-D.ietf-p2psip-base]. The URL of the enrollment server may be 262 provided by an out-of-band mechanism or alternatively, the node 263 can do a DNS SRV query to find an enrollment server. In the 264 RELOAD HIP BONE instance, instead of doing a DNS SRV query using a 265 service name of "p2psip_enroll" to find an enrollment server, the 266 service name "hipbreload_enr" is used. The URL of the enrollment 267 server is formed by appending a path of "hipbone-reload/enroll" to 268 the overlay name. After this, the enrollment and bootstrap 269 procedure continues as defined in RELOAD base 270 [I-D.ietf-p2psip-base], that is, the overlay configuration 271 document is fetched from the enrollment server. 272 o The X.509 certificates used by the RELOAD HIP BONE instance are 273 similar to those of RELOAD except that they contain HITs instead 274 of RELOAD URIs. The HITs are included in the SubjectAltName field 275 of the certificate as described in [I-D.ietf-hip-cert]. 277 The RELOAD HIP BONE instance extends the RELOAD overlay configuration 278 document by adding new elements inside each "configuration" element 279 of the document. These new elements are listed in Section 10. 281 9. NAT Traversal 283 RELOAD relies on the Forwarding and Link Management Layer providing 284 NAT traversal capabilities. Thus, the RELOAD HIP BONE instance 285 implementations MUST implement some reliable NAT traversal mechanism. 286 To maximize interoperability, all implementations SHOULD implement at 287 least [I-D.ietf-hip-nat-traversal]. 289 HIP relay servers are not necessarily needed with this HIP BONE 290 instance since the overlay network can be used for relaying the Base 291 Exchange and further HIP signaling can be done directly between the 292 peers. However, if it is possible that a bootstrap peer is behind a 293 NAT, it MUST register with a HIP relay so that there is a reliable 294 way to connect to it. 296 10. RELOAD Overlay Configuration Document Extension 298 This document modifies the bootstrap-node element of the RELOAD 299 overlay configuration document. The modified bootstrap-node element 300 contains the following elements: 302 address: The locator of the bootstrap node. 303 port: The port of the bootstrap node. 304 hit: The HIT of the bootstrap node. 306 If the bootstrap-node element does not contain a HIT, opportunistic 307 mode SHOULD be used for contacting the bootstrap node. 309 This document also adds a new element inside the configuration 310 element that defines which mode (see Section 4) is used for 311 generating the Node and Resource IDs. The name of the element is 312 "hipbone-id-mode" and the content is the identifier of the mode: 313 "ORCHID" for the ORCHID prefixed IDs and "RELOAD" for the IDs that 314 use the whole 128 bits as defined by the RELOAD specification. 316 11. Security Considerations 318 The option to send overlay messages unencrypted makes it possible for 319 hosts that are not part of the overlay to inspect the contents of the 320 messages and thus should be avoided when possible. If the ENCRYPTED 321 parameter is used instead of encrypted connections, the HIP header 322 remains visible but the contents are protected. 324 Limiting the peer ID and resource ID space into 128 bits (or 100 bits 325 with ORCHID prefixes) results in a higher probability for ID 326 collisions, both unintentional and intentional, than using larger 327 address spaces. 329 12. IANA Considerations 331 This document has no IANA actions. 333 13. References 335 13.1. Normative References 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 341 for Overlay Routable Cryptographic Hash Identifiers 342 (ORCHID)", RFC 4843, April 2007. 344 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 345 "Host Identity Protocol", RFC 5201, April 2008. 347 [I-D.ietf-hip-bone] 348 Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., 349 and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) 350 Based Overlay Networking Environment", 351 draft-ietf-hip-bone-04 (work in progress), January 2010. 353 [I-D.ietf-p2psip-base] 354 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 355 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 356 Base Protocol", draft-ietf-p2psip-base-06 (work in 357 progress), November 2009. 359 [I-D.ietf-hip-nat-traversal] 360 Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 361 Keranen, "Basic HIP Extensions for Traversal of Network 362 Address Translators", draft-ietf-hip-nat-traversal-09 363 (work in progress), October 2009. 365 [I-D.ietf-hip-via] 366 Camarillo, G. and A. Keranen, "Host Identity Protocol 367 (HIP) Multi-hop Routing Extension", draft-ietf-hip-via-00 368 (work in progress), October 2009. 370 [I-D.ietf-hip-hiccups] 371 Nikander, P., Camarillo, G., and J. Melen, "HIP (Host 372 Identity Protocol) Immediate Carriage and Conveyance of 373 Upper-layer Protocol Signaling (HICCUPS)", 374 draft-ietf-hip-hiccups-01 (work in progress), 375 January 2009. 377 [I-D.ietf-hip-cert] 378 Heer, T. and S. Varjonen, "HIP Certificates", 379 draft-ietf-hip-cert-02 (work in progress), October 2009. 381 13.2. Informational References 383 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 384 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 386 Authors' Addresses 388 Ari Keranen 389 Ericsson 390 Hirsalantie 11 391 02420 Jorvas 392 Finland 394 Email: Ari.Keranen@ericsson.com 395 Gonzalo Camarillo 396 Ericsson 397 Hirsalantie 11 398 Jorvas 02420 399 Finland 401 Email: Gonzalo.Camarillo@ericsson.com 403 Jouni Maenpaa 404 Ericsson 405 Hirsalantie 11 406 Jorvas 02420 407 Finland 409 Email: Jouni.Maenpaa@ericsson.com