idnits 2.17.1 draft-matthews-p2psip-hip-hop-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 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1128. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1139. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1146. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1152. 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 abstract seems to contain references ([Concepts]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (June 16, 2007) is 6158 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-08 == Outdated reference: A later version (-02) exists of draft-johnston-sipping-p2p-ipcom-00 == Outdated reference: A later version (-09) exists of draft-ietf-hip-nat-traversal-02 -- No information found for draft-baset-p2psip-p2pcommon - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP Working Group E. Cooper 3 Internet-Draft A. Johnston 4 Intended status: Standards Track P. Matthews 5 Expires: December 18, 2007 Avaya 6 June 16, 2007 8 A Distributed Transport Function in P2PSIP using HIP for Multi-Hop 9 Overlay Routing 10 draft-matthews-p2psip-hip-hop-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 18, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document examines a P2PSIP architecture where the peer-to-peer 44 (P2P) layer is separate from and lies below the SIP layer. We 45 discuss the functions of the P2P layer in such an architecture, and 46 focus in on the Distributed Transport function - the function that 47 allows a peer to exchange messages with any other peer in the 48 overlay, even in the presence of NATs. We list the features that the 49 Distributed Transport function needs to provide, and observe that the 50 Host Identity Protocol (HIP) already provides a number of these 51 features. We then propose extensions to HIP that allow it to provide 52 the missing features. We discuss how a complete P2PSIP architecture 53 can be built around HIP, and contrast this approach with other 54 approaches for implementing a P2P layer. Two of the advantages of 55 HIP approach are that (a) most existing applications can run in an 56 overlay without needing any changes and (b) peer mobility and NAT 57 traversal are handled in a way that is transparent to most 58 applications. 60 Terminology 62 Descriptions of the basic concepts and terminology used in this 63 document can be found in the P2PSIP Concepts and Terminology document 64 [Concepts]. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Distributed Database function . . . . . . . . . . . . . . 5 70 1.2. Overlay Maintenance function . . . . . . . . . . . . . . . 6 71 1.3. Distributed Transport function . . . . . . . . . . . . . . 6 72 1.4. Realizing the Distributed Transport function with HIP . . 8 74 2. Brief Introduction to HIP . . . . . . . . . . . . . . . . . . 9 76 3. Brief Introduction to our HIP extensions . . . . . . . . . . . 12 78 4. What are the alternatives? . . . . . . . . . . . . . . . . . . 13 80 5. Details of our Proposal . . . . . . . . . . . . . . . . . . . 14 81 5.1. Protocol Layering . . . . . . . . . . . . . . . . . . . . 15 82 5.2. Peer IDs . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 5.3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 16 84 5.4. Sending Packets between Peers in the Overlay . . . . . . . 17 85 5.4.1. Routing Packets hop-by-hop through the Overlay . . . . 18 86 5.4.2. Sending packets directly to the destination peer . . . 18 87 5.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 6. One Possible Implementation . . . . . . . . . . . . . . . . . 22 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 95 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 97 10. Informative References . . . . . . . . . . . . . . . . . . . . 23 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 100 Intellectual Property and Copyright Statements . . . . . . . . . . 26 102 1. Introduction 104 Consider the architecture for a P2PSIP peer shown in Figure 1. 106 _________________________ 107 | SIP | Other applications ... 108 |_________________________|_________________________ 109 | . . . . . . . . . . . . . . . . . . . . . . . . | 110 | Distributed Database : : Overlay Maintenance | 111 P2P Layer | . . . . . . . . . . . : . : . . . . . . . . . . . | 112 | Distributed Transport | 113 |___________________________________________________| 115 Figure 1 117 In this architecture, there is a P2P layer which is distinct from the 118 SIP layer, and which provides services to the SIP layer and other 119 applications. This P2P layer is internally divided into three parts, 120 each of which provides a distinct function to the upper layers. 121 These three functions are: 123 o Distributed Database. This allows peers to store and retrieve 124 information. The initial envisioned use of this database is to 125 store Address-of-Record (AoR) to Contact mappings for users, but 126 it seems likely that this database will be used to store other 127 things as P2PSIP evolves. 129 o Overlay Maintenance. This establishes and maintains peer 130 connections, distributes overlay configuration information to 131 peers, and does anything else required to maintain the overlay. 133 o Distributed Transport. This allows a peer to send an arbitrary 134 packet to any other peer in the overlay, even if the destination 135 peer is behind one or more NATs. This is the most basic function 136 of the three, and is used by the other two functions. 138 The SIP layer utilizes the functions provided by the P2P layer to set 139 up multimedia sessions between peers. SIP queries the Distributed 140 Database function to resolve an AoR to one or more Contact addresses, 141 and then uses the Distributed Transport function to deliver SIP 142 messages to the remote peer(s). Note that SIP and other applications 143 can access the Distributed Transport function directly without going 144 through the other two functions. 146 It is important to note that we are proposing that the P2P layer 147 provide these functions to all upper-layer protocols, not just SIP. 149 The authors strongly believe that people will want to run protocols 150 other than SIP over P2PSIP overlays, and providing a solution that 151 works only for SIP will just encourage people to run these other 152 protocols over SIP - a solution which goes directly against 153 [RFC4485]. 155 This architecture proposal is not new. The initial suggestion to use 156 this architecture for P2PSIP was made by us two years ago in [IPCom] 157 and [Industrial], and has been explored by others in some detail in 158 [P2P-Arch] and [P2PCommon]. The contribution of this document is not 159 in suggesting the architecture, but in making a concrete suggestion 160 for how to realize it that leverages a large body of existing work. 162 This architecture stands in contrast to the dSIP architecture [dSIP], 163 where there is not a distinct P2P layer, but instead the SIP and P2P 164 layers are merged and the functions of the P2P layer are implemented 165 using an extended version of SIP. 167 In the following subsections, we examine in more detail the functions 168 that the P2P layer provides in this architecture. 170 1.1. Distributed Database function 172 This function provides a way for upper-layer applications to provide 173 and retrieve data that is actually stored by distributing the data 174 out to the peers in the overlay. 176 In particular, the Distributed Database function provides the 177 following: 179 o Distribution of data across peers in the overlay in a way such 180 that no one peer needs to store all the data (unless there is only 181 one peer in the overlay); 183 o Replication and shuffling so that data is not lost if one or more 184 peers leave the overlay; 186 o Security (to the extent possible) to verify the origin of the data 187 and guard against malicious data modification by other peers; 189 o Put and Get operations to store and retrieve the data from the 190 distributed database. 192 There have already been some proposals for how the Distributed 193 Database function might be realized. For example, [P2PCommon] 194 proposes Insert, Lookup, and Remove messages that implement these 195 many of the above features. We believe that these messages could be 196 easily modified to work with the Distributed Transport design 197 described here. 199 1.2. Overlay Maintenance function 201 The Overlay Maintenance function provides the controls that causes 202 the peers in the overlay to function together in a harmonious way. 204 For example, the Overlay Maintenance function provides the following: 206 o Admission of peers to the overlay, including checking the 207 credentials of peers to make sure they are authorized to join; 209 o Controlling the creation of connections in the overlay to ensure 210 that the appropriate pattern of connections exists for efficient 211 routing and lookup; 213 o Distributing information about the overlay that needs to be known 214 by all (or a subset) of the peers. This might include the name of 215 the overlay, the values to use for adjustable parameters, 216 encryption keys for data that all peers can read but nodes outside 217 the overlay cannot, etc. This information is likely given to a 218 peer when it joins the overlay, but there may be ways an 219 administrator can change certain values without having to break up 220 the overlay and allowing it to re-form. 222 This document does not propose an Overlay Maintenance protocol, 223 leaving this to future work. However, later in this document we 224 describe the role of the Overlay Maintenance protocol in driving the 225 routing feature of the Distributed Transport function. 227 1.3. Distributed Transport function 229 The Distributed Transport function provides a way to uniquely 230 identify peers and to deliver messages to an arbitrary peer in the 231 presence of NATs and mobile peers. 233 The presence of NATs has a major influence on this function, since 234 NATs often hinder two peers from exchanging data directly. The 235 proposed approach for solving this problem is to establish a partial 236 mesh of connections between peers, and then allow data to be sent 237 indirectly between peers by sending it along existing connections in 238 the overlay . To make this possible, there must be a way to identify 239 a peer (a peer ID), a way to establish and maintain connections, and 240 a way to add the destination peer ID to the packet. In essence, the 241 overlay forms a network, with peer IDs serving as addresses, 242 connections serving as links, peers serving as routers, and the tag 243 serving as a network layer header. 245 Having peer IDs also makes it possible to gracefully handle mobile 246 peers. If a peer changes its IP address, then this could be 247 considered equivalent to the peer leaving the overlay and later 248 rejoining with a new IP address, but it is better if this could be 249 viewed as simply a change in the address used to contact the peer. 251 Providing these functions at the P2P layer means that applications 252 themselves do not need to worry about NAT traversal and mobility. 253 This is a big advantage over competing approaches that require each 254 application to handle these on their own. 256 The approach mentioned above provides datagram delivery, but to be 257 useful, the Distributed Transport function must also provide all the 258 usual transport layer services that applications depend upon. For 259 example, the Distributed Transport function must provide services 260 like TCP and TLS. If these services are not provided, then the 261 P2PSIP WG will have to redo a large collection of SIP-related 262 standards that depend on these services being available. 264 Thus the Distributed Transport function provides the following: 266 o Peer IDs: A unique identifier for each peer in the overlay. 268 o Network layer: The ability to deliver a message to an arbitrary 269 peer in the overlay. In our view, this involves adding a header 270 to the message that specifies the destination peer ID and then 271 routing that message along existing connections in the overlay to 272 the destination peer. 274 o Signaling: The ability to add, maintain, and remove connections in 275 the overlay. The signaling procedures must work in the presence 276 of NATs. 278 o Bootstrapping: The ability for a peer that is not currently a 279 member of the overlay to locate and establish an initial 280 connection to a peer in the overlay. 282 o Transport layer: The usual transport layer functions such as port 283 numbers, reliable in-order delivery of messages (if desired), and 284 the segmentation of user data into Path-MTU-sized chunks (if 285 desired). This also includes transport layer security (TLS and 286 DTLS ) if desired. 288 o Mobility and Multihoming: The ability for a peer have multiple IP 289 addresses and to change these addresses dynamically while 290 remaining a member of the overlay. In make-before-break scenarios 291 (= adding new addresses before losing all the old addresses), this 292 is seamless; in break-before-make scenarios, connections go down 293 and must be re-established but the peer remains part of the 294 overlay. 296 o Security: Message integrity and sequencing to prevent outsiders 297 and intermediate peers from corrupting or replaying messages; 298 encryption to prevent the message body from being read by 299 outsiders or intermediate peers; protection against DoS attacks 300 from outsiders or (to the extent possible) from intermediate 301 peers. 303 The following figure shows a simple example of some of these 304 concepts. 306 Peer E 307 O 308 / | \ 309 Peer D O | O Peer F 310 / | \ | \ 311 Peer C O | \--- O Peer G 312 \ | | \ / 313 Peer B O | O Peer H 314 \ | / 315 O 316 Peer A 318 Figure 2 320 Figure 2 shows a number of peers arranged in an overlay network. 321 Each peer in the network is behind its own NAT. Each peer has one or 322 more connections to other peers in the overlay. If peer H wants to 323 send a packet to peer B, it could try to send the packet directly, 324 but most likely the filtering property of B's NAT would prevent the 325 packet from getting through. So peer H has two options: (a) it can 326 send the packet to peer A which then forwards it to peer B, or (b) it 327 can set up a direct connection to peer B, using ICE-like signaling 328 procedures [ICE], and then send the packet directly to B. 330 1.4. Realizing the Distributed Transport function with HIP 332 In this document, we propose to realize the Distributed Transport 333 function with an extended version of the Host Identity Protocol (HIP) 334 [HIP-Base] currently being developed in the HIP WG. We describe how 335 HIP currently provides a number of the Distributed Transport features 336 listed in the previous section, and then describe how to extend HIP 337 to provide the remaining features. We contrast this approach of 338 using HIP with the approach of producing a new protocol from scratch, 339 and conclude that HIP is such a good fit that any compelling new 340 protocol would end up stealing many ideas from HIP. 342 The current version of this document is not a fully fleshed-out 343 proposal, but rather a high-level presentation of the big picture. 344 In many cases, we only describe the key ideas behind a proposed HIP 345 extension, or the key ideas on how a Distributed Transport feature 346 can be realized using either existing or proposed HIP features. We 347 have taken this approach in part to keep the document short and 348 readable, but mostly because in many cases we have not work out the 349 details. In addition, some of this work is perhaps best done in the 350 HIP WG rather than the P2PSIP WG. We expect that future revisions of 351 this document and/or follow-on documents will provide more details. 353 2. Brief Introduction to HIP 355 In this section, we give a brief introduction to HIP and how it is 356 used in our proposal. This section is especially targeted at those 357 who know little or nothing about HIP. The goal is to give the reader 358 a sense that HIP has a lot to offer P2PSIP. 360 The Host Identity Protocol (HIP) is an alternative to the dual use of 361 IP addresses as "locators" (routing labels) and "identifiers" (host 362 identifiers). In HIP, the transport layer is decoupled from the 363 network layer by introducing an identifier for a host which is 364 independent of the host's IP address(es). Though this decoupling, 365 the transport layer and the applications above it are mostly 366 insulated from changes in IP addresses. This host identifier concept 367 of HIP is very similar to the peer ID concept of P2PSIP. 369 In HIP, hosts are identified using two closely-related concepts: 371 o A Host Identity (HI), which is the public half of a public/private 372 key pair; and 374 o A Host Identity Tag (HIT), which is a 128-bit SHA-1 hash of a Host 375 Identity. 377 An HI is the definitive identification for a host. HIs are long- 378 lived, but it is easy for a host to have multiple HIs, and it is 379 possible for hosts to create HIs without needing to access a central 380 server. 382 The HIT is a compact (128-bit) shorthand for the HI with the 383 following properties: 385 o It uniquely identifies the host. The HIT is large enough to make 386 it extremely unlikely that two different HIs will generate the 387 same HIT. 389 o It is self-certifying. That is, given a HIT, it is 390 computationally hard to find a Host Identity that matches the HIT. 392 o It looks like an IPv6 address. The first 20 bits of a HIT are 393 fixed, and the corresponding range of IPv6 addresses have been 394 reserved for HITs. Thus a HIT can be used anywhere an IPv6 395 address can be used, while retaining the ability to distinguish a 396 HIT from a regular IPv6 address. This has huge advantages, both 397 when extending protocols to work with HIP, and when adapting 398 existing protocol implementations and APIs to work with HIP. 400 In our proposal, the HIT serves as the peer ID that applications use 401 to uniquely identify peers in the overlay. 403 The HIP protocol itself is a signaling protocol for setting up, 404 maintaining, and tearing down security associations between two 405 hosts. Associations are created using a four-packet exchange. The 406 first party is called the Initiator and the second party the 407 Responder. The four-packet design helps to make HIP DoS resilient. 408 The protocol exchanges Diffie-Hellman keys in the 2nd and 3rd 409 packets, and authenticates the parties in the 3rd and 4th packets. 410 Once the association is established, HIP defines other procedures for 411 maintaining this association, even in the case where one or both ends 412 change their IP address. 414 To allow the HIP association to traverse intervening NATs, HIP uses a 415 variation of the ICE protocol [ICE]; see [NAT-Traversal-for-HIP]. 417 A HIP association is logically a connection between two hosts. Once 418 an association between two hosts is set up, HIP multiplexes all 419 application-level protocols over the association. This is done by 420 running the standard Internet transport protocols over the 421 association, and using port numbers for demultiplexing in the usual 422 manner. 424 In our proposal, HIP is used in two different ways: (a) the HIP 425 signaling procedures are used as an important first step in setting 426 up and maintaining a connection in the overlay, and (b) HIP is 427 extended to act as an encapsulation protocol for carrying upper-layer 428 application data hop-by-hop through the overlay. 430 The HIP header is illustrated in Figure 3. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Next Header | Header Length |0| Packet Type | VER. | RES.|1| 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Checksum | Controls | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Sender's Host Identity Tag (HIT) | 440 | | 441 | | 442 | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Receiver's Host Identity Tag (HIT) | 445 | | 446 | | 447 | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 / HIP Parameters / 451 / / 452 | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Figure 3 457 The header contains the following fields: 459 o Next Header: Specifies the protocol that follow (lies above) HIP. 461 o Header Length: The total length of the header, including any 462 optional HIP parameters. 464 o Packet Type: There are currently 8 different HIP packet types 465 defined. 467 o Version. 469 o Checksum: A checksum over the header. 471 o Controls: A set of one-bit flags. Only one is currently defined. 473 o Source (sender) and Destination (receiver) HITs. 475 o HIP Parameters. Optional TLVs that carry additional information. 476 A number of TLVs are currently defined. 478 3. Brief Introduction to our HIP extensions 480 The previous section described the features that HIP offers today and 481 how it provides some of the features of the Distributed Transport 482 function. In this section, we sketch the extensions to HIP required 483 to provide the remaining features. The goal of this section is to 484 give a quick overview of these extensions; more details are provided 485 later. 487 The HIP extensions that we propose in this document are: 489 o Encapsulation of higher-level messages. HIP as currently defined 490 is a signaling protocol only. To extend HIP to serve an 491 encapsulation protocol for higher-layer messages to transport them 492 hop-by-hop through the overlay, we exploit the fact that HIP 493 header (Figure 3) already has a Next Protocol field. Thus 494 encapsulating higher-layer messages is simply a matter of defining 495 a codepoint for a new Packet Type (which we call the Data packet) 496 which is used to carry the higher-layer messages. 498 o Hop-by-hop routing through an overlay. HIP as currently defined 499 is a protocol for setting up a point-to-point security association 500 between two hosts. To extend it to provide multi-hop routing 501 between peers in an overlay, we exploit the fact that the HIP 502 header (Figure 3) contains the source and destination HITs (= peer 503 IDs). Thus doing multi-hop routing is simply a matter of defining 504 how to forward a HIP message in the case when the peer receiving 505 the message is not the destination peer listed in the header. 507 o Bootstrapping. In [Bootstrap], the authors described procedures 508 that allowed a joining peer to locate and establish a connection 509 to an admitting peer in an overlay. Those procedures were defined 510 using SIP as the signaling protocol, but these procedures can also 511 be realized using HIP as the signaling protocol. 513 o Efficient transport of SRTP. HIP inserts an extra layer into the 514 standard networking stack, and two layers when there is a NAT 515 between the two peers. For protocols like the Secure Real-Time 516 Protocol (SRTP), these extra layers can cause problems. We show 517 how the usual protocol stack (e.g., SRTP / UDP / IP) can be used 518 in these situations, while maintaining the NAT traversal, multi- 519 homing, and mobility properties of our version of HIP. 521 More details on these extensions and other aspects of our proposal 522 can be found in Section 5. 524 4. What are the alternatives? 526 Before we jump into the details of our proposal, it is worth 527 considering what an alternative design for the Distributed Transport 528 layer would look like if the P2PSIP group was not to use HIP but 529 design one from scratch. For the authors, it was a real breakthrough 530 when we realized that any protocol we designed from scratch to be a 531 Distributed Transport layer would likely re-invent much of HIP. 533 To start with, consider the format of a peer ID. In [dSIP] and 534 elsewhere, it is proposed that P2PSIP use 160-bit peer IDs. To use 535 these peer IDs, [dSIP] and [Bootstrap] propose to extend the URI 536 scheme of SIP to express peer IDs, perhaps by adding a "peerid=" 537 parameter to the URI. There are two problems with this approach: (a) 538 every application that wants to work in an overlay has to be extended 539 to understand the new URI scheme, and (b) new procedures have to be 540 defined to describe how an application resolves this URI. A counter- 541 argument might be made that many DHTs today are defined to work with 542 160-bit hashes, but the authors believe that all the major DHTs today 543 can be easily adapted to work with a 128-bit peer ID. 545 By contrast, the approach of HIP is to make a peer ID (= HIT) look 546 like an IPv6 address. With this approach, in most cases the existing 547 approaches for resolving a URI to an address continue to work if 548 (behind the scenes) a peer ID is returned instead of an address. As 549 we show below, this means that most applications need no changes to 550 work in an overlay. From this, we conclude that the advantages of 551 making a peer ID look like an IPv6 address are substantial, and any 552 alternate proposal for P2PSIP would need strong reasons to take a 553 different approach. 555 Next, consider the design of the "network layer" header, and consider 556 the fields that would be needed in this header if the P2PSIP WG was 557 to design its own protocol header. Most likely, these fields would 558 include: 560 o Source and destination peer ID (required for routing around the 561 overlay); 563 o Demux field for indicating the higher-layer protocol (required to 564 determine the upper-layer protocol); 566 o Protocol version number; 568 o Packet type field (if the protocol also does signaling or other 569 things); 571 o Optional TLVs for extensibility; 573 o Some way to detect the end of the header when optional TLVs are 574 present; for example, a header length field. 576 Comparing with the HIP header in section, we see that only the Header 577 Checksum and Controls fields might be eliminated, and even these 578 fields can be easily argued for. From this, we conclude that the HIP 579 header extremely well-suited for the Distributed Transport layer. 581 Next, consider the signaling protocol. The basic functions of the 582 HIP signaling protocol (setting up, maintaining, and tearing down 583 connections, handling endpoint mobility, reporting errors, etc) are 584 the same as a dedicated P2PSIP protocol would need. Though it is 585 possible, perhaps even likely, that a P2PSIP design team would make 586 some different design choices, the resulting protocol would likely 587 have all the same basic properties. 589 Finally, consider the transport layer functions. In HIP, these are 590 performed by the existing transport layer protocols (TCP, UDP, TLS, 591 etc) using the existing APIs (sockets, etc.), exploiting the fact 592 that HITs look like IPv6 addresses. In this way, little or no 593 changes are required to existing applications. This makes for a very 594 compelling story in comparison with the alternatives of developing 595 new APIs and/or new protocols. 597 5. Details of our Proposal 599 This section gives the details of our proposal for using an extended 600 version of HIP for the Distributed Transport function of P2PSIP. 602 While reading this proposal, there are a few facts that reader should 603 keep in mind: 605 o The proposal does NOT require the underlying network to be IPv6. 606 Though peer IDs look like IPv6 addresses at the application layer, 607 the underlying network addresses can be IPv4, IPv6, or a mixture 608 of the two. 610 o Only peers and bootstrap servers need to run the HIP-related 611 protocols. No changes are required on other nodes in the network 612 (e.g., routers, client-server SIP nodes, or other nodes that 613 interact with the overlay). 615 The following sections give a high-level view of the proposal. More 616 details will be provided in subsequent versions and/or separate 617 documents. 619 5.1. Protocol Layering 621 Figure 4 shows the fundamental protocol layering in our proposal. 623 _________________________ 624 | SIP | Other applications ... 625 |_________________________|_________________________ 626 | . . . . . . . . . . . . . . . . . . . . . . . . | 627 | Distributed Database : : Overlay Maintenance | 628 | . . . . . . . . . . . : . : . . . . . . . . . . . | 629 | TCPv6, UDPv6, TLS, etc. | 630 | . . . . . . . . . . . . . . . . . . . . . . . . . | 631 P2P Layers | HIP or ESP | 632 | . . . . . . . . . . . . . . . . . . . . . . . . . | 633 | UDPv4 : UDPv6 | 634 |_________________________:_________________________| 635 | IPv4 | IPv6 | 636 |_________________________|_________________________| 638 Figure 4 640 In Figure 4, the Distributed Transport box of Figure 1 has been 641 replaced by three sub-layers. The upper sub-layer is the existing 642 Internet transport layer, consisting of protocols such as TCP, UDP, 643 SCTP, DCP, etc along with extensions such as TLS and DTLS. These are 644 the v6 versions of these protocols, since HITs (peer IDs) look like 645 IPv6 addresses. 647 The middle sub-layer is the HIP/ESP layer. HIP is used for signaling 648 and for encapsulation of data packets in multi-hop scenarios, while 649 ESP (Encapsulated Security Payload) [HIP-ESP] is used for 650 encapsulation in single-hop scenarios -- we discuss this in more 651 detail below. 653 The lower sub-layer is a UDP encapsulation layer. This layer is 654 present because most NATs, firewalls, and other middleware boxes 655 today do not understand HIP and will usually drop a packet if the 656 protocol above the IP layer is not TCP or UDP. Placing a UDP header 657 between IP and HIP will allow HIP packets to traverse these boxes. 658 This layer is used only when required. Using ICE-like connectivity 659 checks, HIP detects if packets without this encapsulation layer can 660 make it through and eliminates this layer when it is not needed. 662 This stack runs over either IPv4 or IPv6. A peer can have both IPv4 663 and IPv6 interfaces, and connections in the overlay can be a mixture 664 of these two protocols. 666 NOTE: Readers concerned about how to implement Figure 4 may wish to 667 jump ahead to Section 6 before reading further. 669 5.2. Peer IDs 671 Host Identities could be assigned to peers in at least two different 672 ways. One way is for peers to generate their own public/private key 673 pairs. Another way is to allocate them to peers, perhaps in 674 conjunction with a set of credentials, using a centralized allocation 675 system. The pros and cons of these and other schemes requires 676 further investigation. 678 Once a Host Identity is allocated to a peer, the peer uses the 679 standardized method to form its HIT [HIP-Base]. 681 A HIT is the typical way to identify a peer in the overlay. Because 682 a HIT fits in an IPv6 address, in many cases applications need not be 683 aware that they are talking to a peer in an overlay, and many IPv6- 684 ready applications can run in an overlay without changes. Consider 685 an application that uses the IPv6 form of the socket API, uses HITs 686 to identify peers on the overlay, and uses IPv4 addresses (in IPv4- 687 in-IPv6 format) and/or IPv6 addresses to identify nodes off the 688 overlay. In many situations, the application can freely mix these 689 three formats internally, leaving the transport and HIP layers to 690 sort out the differences. The exceptions are cases where the 691 application would otherwise do something like send a HIT to an IPv4- 692 only node not on the overlay. 694 5.3. Signaling 696 In our proposal, there are two layers of signaling involved in 697 establishing, maintaining, and terminating connections in the 698 overlay. The HIP layer is responsible for establishing, maintaining, 699 and terminating HIP associations with other nodes. The nodes may be 700 peers in the overlay, or they may be ordinary nodes with which a HIP 701 association is desired. The Overlay Maintenance layer is responsible 702 for admitting some of these HIP associations to the overlay, and for 703 ensuring that the pattern of connections in the overlay follow the 704 pattern required for the DHT or other protocol. In this section, we 705 discuss HIP signaling for overlays in more detail, and leave the 706 discussion of Overlay Maintenance signaling to other documents. 708 Establishing a new HIP association within an overlay falls into one 709 of two cases: (a) the initiating peer is not currently in the overlay 710 and is trying to establish its first connection to another peer in 711 the overlay, and (b) the initiating peer is already in the overlay. 712 The basic format of the signaling exchange is the same in both cases; 713 the difference is in how the HIP signaling messages are routed 714 between the two peers. 716 In case (a), procedures similar to those in [Bootstrap] are used. 717 [Bootstrap] defines two mechanisms for a joining peer to locate an 718 admitting peer: using a Bootstrap Server and using multicast. HIP 719 already a mechanism similar to the Bootstrap Server mechanism (the 720 RVS mechanism) which is used to locate a single node -- in our 721 proposal, this mechanism is extended to work with overlays. The key 722 idea is to identify the overlay either by name, or by assigning a HIT 723 to the overlay itself. In that way, the bootstrap peers can register 724 with the Bootstrap Server using the overlay name or HIT, and the 725 Bootstrap Server can route HIP I1 packets (= the first packet in the 726 HIP signaling exchange) received from the joining peer to a bootstrap 727 peer associated with the overlay. For the multicast mechanism, a 728 similar approach is used: a multicast I1 packet specifying the 729 overlay to join is sent out by the joining peer, one or more 730 bootstrap peers reply, and the joining peer selects one to continue 731 the exchange with. 733 In case (b), the signaling messages are delivered to the remote peer 734 by routing them hop-by-hop through the overlay (section 4.4.1). The 735 initiating peer places the HIT of the remote peer into the I1 message 736 and sends the I1 message to its direct neighbor which is closest to 737 the remote peer, and the I1 message is then routed hop-by-hop to the 738 remote peer. In this way, the originator does not need have a priori 739 knowledge of the remote peer's IP address, and the signaling messages 740 can be delivered even if the remote peer is behind a NAT or firewall. 742 At any time, a given peer may have some associations which are a part 743 of one overlay, some associations which are part of other overlays, 744 and some associations which are not part of any overlay (or 745 equivalently, a part of a 2-node overlay only). The question of 746 whether a given HIP association can be simultaneously part of two 747 different overlays is for further study. 749 5.4. Sending Packets between Peers in the Overlay 751 There are two ways to send a packet to another peer in the overlay: 752 send it on a direct connection to the remote peer, or send it hop-by- 753 hop through the overlay. A peer typically uses hop-by-hop routing 754 when it has only a small amount of data to transfer to the remote 755 peer (for example, a Distributed Database update or a SIP INVITE 756 transaction), and sets up a direct connection when it has a larger 757 amount of data to transfer (for example, an RTP session). 759 5.4.1. Routing Packets hop-by-hop through the Overlay 761 To route a packet hop-by-hop through the overlay, it must have a HIP 762 header. In this HIP header, the sender field gives the HIT of the 763 peer sending the packet, and the receiver field gives the HIT of the 764 peer to which the packet is destined -- this might be a peer that is 765 multiple hops away. 767 The HIP packet might be one of the existing packet types uses to set 768 up and maintain HIP associations, or it might be a new packet type 769 called Data that is used to encapsulate messages from higher-layer 770 protocols and carry them hop-by-hop through the overlay. This new 771 packet type has the HIP header shown in Figure 3, a packet type of 772 "Data" (codepoint is TBD), and the Next Protocol field in the header 773 is used to indicate the encapsulated protocol. 775 We then extend HIP with the concept of multi-hop routing. When a HIP 776 packet arrives at a peer, the packet is delivered to the HIP layer 777 which checks if the destination HIT is a HIT that belongs to this 778 peer. If not, then the peer tries to forward the packet. To do 779 this, the peer must decide which of its (directly connected) 780 neighboring peers to forward the packet to. This is done by having 781 the HIP layer consult a table, called the HFIB (HIP Forwarding 782 Information Base), which plays a role similar to the FIB table used 783 in IP forwarding by routers. The calculation of the HFIB is done by 784 the Overlay Maintenance layer and downloaded to the HIP layer. 786 The Overlay Maintenance layer constructs the HFIB using the principle 787 of greedy routing, where at each hop, packets are forwarded to the 788 neighboring peer whose peer ID is the closest match to the 789 destination peer ID. This is the routing approach used in most DHT 790 algorithms (Chord, Bamboo, Kademlia, etc). The Overlay Maintenance 791 layer makes this routing algorithm efficient by adding the 792 appropriate connections to the overlay. More discussion of this 793 approach can be found in [NATs-and-Overlays]. 795 It is possible for given peer to be a member of multiple overlays. 796 It is also possible for a peer to have HIP associations with nodes 797 that are not part of an overlay. In these case, a peer needs to know 798 on which overlay (or otherwise) a given packet should be forwarded. 799 One way to solve this problem is to include the overlay ID in a TLV 800 in the HIP header. This is an area of ongoing investigation. 802 5.4.2. Sending packets directly to the destination peer 804 The second way to send a packet to a peer in the overlay is to 805 establish a direct connection to the remote peer, and then send the 806 packets directly. 808 When sending a packet on a direct connection to the destination peer, 809 the relatively large HIP header (40 bytes) can be replaced with 810 something smaller. In this document, we discuss two replacements: 811 the first is currently defined for used with HIP, while the second is 812 a proposed extension. 814 The first alternative is shown in Figure 5. 816 _________________________ 817 | SIP | Other applications ... 818 |_________________________|_________________________ 819 | . . . . . . . . . . . . . . . . . . . . . . . . | 820 | Distributed Database : : Overlay Maintenance | 821 | . . . . . . . . . . . : . : . . . . . . . . . . . | 822 | TCPv6, UDPv6, TLS, etc. | 823 | . . . . . . . . . . . . . . . . . . . . . . . . . | 824 P2P Layers | ESP | 825 | . . . . . . . . . . . . . . . . . . . . . . . . . | 826 | UDPv4 : UDPv6 | 827 |_________________________:_________________________| 828 | IPv4 | IPv6 | 829 |_________________________|_________________________| 831 Figure 5 833 Here HIP has been replaced with ESP (Encapsulated Security Payload) 834 [HIP-ESP]. ESP serves two functions when used in this way: 836 o It provides optional encryption, optional message integrity, and 837 protection against replay attacks. The pros and cons of using ESP 838 vs. TLS/DTLS for this purpose in P2PSIP overlays in an area of 839 ongoing investigation. 841 o It provides a field, called the SPI (Security Parameter Index), 842 which is used as a shorthand for the (source, destination) HIT 843 pair. In this way, the receiver can determine the source and 844 destination HITs to associate with the packet. 846 Following the lead of the HIP WG, this protocol stack is the default 847 when sending a packet directly from the source to the destination. 849 The advantage of the protocol stack in Figure 5 is that it provides a 850 smaller header (8 bytes for ESP vs. 40 bytes for HIP), while 851 maintaining the separation between the transport layer and the IP 852 layer that allows the IP addresses to change without affecting the 853 transport layer. For most applications, this protocol stack 854 represents a good tradeoff between efficiency and flexibility. 856 However, for some applications, the protocol stack in Figure 5 is 857 inappropriate. A good example is SRTP, where a small header is very 858 important, where there has been a fair amount of work on compressing 859 the header further [RFC3095], and where the security properties of 860 ESP are unnecessary since these properties are already provided by 861 the application protocol. 863 For those applications, a second protocol stack is available, as 864 shown in Figure 6. 866 _______________ 867 | SRTP | Other apps... 868 |______________|______________ 869 P2P Layer | UDP(v4/v6) | 870 |_____________________________| 871 | IP(v4/v6) | 872 |_____________________________| 874 Figure 6 876 Here the default protocol layering on direct connections (shown in 877 Figure 5) has been replaced with an alternative layering. This is 878 not a general-purpose layering; this layering must be explicitly 879 negotiated by the two peers before it can be used and is available 880 only for the specific combinations of (local HIT, local port, remote 881 HIT, remote port, protocol=UDP) that have been negotiated. For all 882 other combinations, the two peers continue to use the layering of 883 Figure 5. 885 When a packet is received at a peer with this layering, the 886 combination of (local IP address, local port, remote IP address, 887 remote port, protocol=UDP) is used to map this packet to a specific 888 (local HIT, local port, remote HIT, remote port, protocol=UDP) 889 combination. In this way, both the HIT pair and the destination 890 application are identified. 892 To negotiate this usage between two peers, one end (peer X) sends a 893 HIP message to the other (peer Y) saying that it would like to 894 negotiate an alternative protocol layering for a particular UDP port 895 combination. Peer X includes a set of ICE candidates to use for the 896 alternative layering; in ICE terms this can be viewed as another 897 media stream between the two peers (where the HIP association is the 898 primary media stream). If peer Y is agreeable, it replies with its 899 own set of candidates, and the two peers then run connectivity checks 900 to select a valid pair. Later, if one endpoint changes its IP 901 address, the two peers negotiate a new valid candidate pair. 903 Since the use of this alternative protocol layering requires extra 904 HIP messaging between the two peers to establish and maintain the 905 additional "media stream", its use is recommended only in situations 906 where the alternate protocol layering is important. In most 907 situations, the default protocol layering of Figure 5 is quite 908 sufficient. 910 From a HIP protocol perspective, this mechanism can be viewed as an 911 instance of a more general mechanism for negotiating alternative 912 protocol layerings. However, it is worthwhile noting that the 913 details of doing a similar layering for TCP are significantly more 914 complex. Consider the case where peer Y changes IP address when peer 915 X has a number of unacknowledged segments outstanding. The sequence 916 numbers of the new TCP connections must be related back to the old 917 TCP connection to allow segments on the new connection to acknowledge 918 segments on the old connection. The details and even the 919 desirability of supporting this is left for future study. 921 5.5. Security 923 Security in HIP can be divided into two areas. The first is the 924 security of the HIP protocol itself, the second is the security 925 provided to the upper layers. 927 For the first, HIP currently provides encryption, message integrity, 928 and protection against replay and denial-of-service attacks against 929 HIP itself. We believe that these mechanisms extend in a straight- 930 forward way to multi-hop message exchanges, though we have not yet 931 investigated all the details. 933 For the second, more investigation is needed to determine whether the 934 security of application protocols should be provided by the HIP/ESP 935 layer, provided at the transport layer by mechanisms such as TLS/ 936 DTLS, or provided at the application layer. The answer will probably 937 be application-dependent. For SRTP, protection at the application 938 layer seems appropriate. For SIP, protection at the transport layer 939 seems appropriate, since SIP is already defined to use TLS over TCP. 941 For many applications, there is an interesting question of whether 942 TLS or ESP is most appropriate. ESP seems to provide security only 943 on an overlay-hop-by-overlay-hop basis, while TLS provides end-to-end 944 security even across multiple overlay hops. ESP may be appropriate 945 if the goal is to protect against outside attacks, while TLS may be 946 more appropriate if the goal is to also protect against attacks from 947 rogue peers. 949 6. One Possible Implementation 951 Consider implementing this proposal on a device which is IPv4-only 952 and has a networking stack built into the OS that you cannot change. 953 One way to do this is shown in Figure 7. 955 __________________ 956 | (S)RTP | SIP | Other apps 957 |________|_________| 958 ______________________________ 959 | Distrib DB | Overlay Maint | 960 |______________|_______________| 962 Socket API (v6) .............................. 963 _________________________ 964 | TCPv6 | UDPv6 | 965 |____________|____________| 966 | HIP / ESP | 967 |_________________________| 968 User 969 Space 970 Socket API (v4) ...................................................... 971 ___________________________________________ Kernel 972 | TCPv4 | UDPv4 | Space 973 |_____________________|_____________________| 974 | IPv4 | 975 |___________________________________________| 977 Figure 7 979 In Figure 7, a standard IPv4 stack is built into the kernel and is 980 accessed via the IPv4 version of the socket API. The HIP/ESP layer, 981 with a second copy of the TCP/UDP layer, is located in user space and 982 is accessible via the IPv6 version of the socket API. The HIP/ESP 983 layer uses the socket-v4 interface into the kernel to send and 984 receive packets. (Note: the v6 and v4 versions of the TCP and UDP 985 protocols differ only in how their checksums are computed). The 986 Distributed DB and Overlay Maintenance protocols live above the 987 socket-v6 interface and uses that API to send and receive packets. 988 Finally, the P2PSIP applications (SIP, (S)RTP, etc.) use the services 989 of all the lower layers. If there is just one process that 990 participates in the P2PSIP overlay, then all the layers shown in user 991 space could be bundled together in that process. 993 Open-source code for many of the pieces in this diagram are available 994 today (albeit without the HIP extensions described above). 996 7. IANA Considerations 998 The present version of this document introduces no new IANA 999 considerations. 1001 8. Security Considerations 1003 The present version of this document gives only a high-level 1004 description of the proposal. A detailed security analysis will be 1005 provided in subsequent versions and/or related documents that 1006 describe the detailed mechanisms. 1008 9. Acknowledgments 1010 The authors thank Spencer Dawkins, Dean Willis, Kevin Chen, and Scott 1011 Hutchens for their helpful comments on this document. 1013 10. Informative References 1015 [Bootstrap] 1016 Cooper, E., Johnston, A., and P. Matthews, "Bootstrap 1017 Mechanisms for P2PSIP", Internet 1018 Draft draft-matthews-p2psip-bootstrap-mechanisms. 1020 [Concepts] 1021 Bryan, D., Matthews, P., Shim, E., and D. Willis, 1022 "Concepts and Terminology for Peer to Peer SIP", Internet 1023 Draft draft-willis-p2psip-concepts-04, March 2007. 1025 [HIP-Base] 1026 Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 1027 "Host Identity Protocol", Internet 1028 Draft draft-ietf-hip-base-08, June 2007. 1030 [HIP-ESP] Jokela, P., Moskowitz, R., and P. Nikander, "Using ESP 1031 transport format with HIP", Internet 1032 Draft draft-ietf-hip-esp-06, June 2007. 1034 [ICE] Rosenberg, J., "Interactive Connectivity Establishment 1035 (ICE): A Methodology for Network Address Translator (NAT) 1036 Traversal for Offer/Answer Protocols", Internet 1037 Draft draft-ietf-mmusic-ice. 1039 [IPCom] Johnston, A., "SIP, P2P, and Internet Communications", 1040 Internet Draft draft-johnston-sipping-p2p-ipcom-00, 1041 January 2005. 1043 [Industrial] 1044 Matthews, P. and B. Poustchi, "Industrial-Strength P2P 1045 SIP", Internet 1046 Draft draft-matthews-sipping-p2p-industrial-strength-00, 1047 February 2005. 1049 [NAT-Traversal-for-HIP] 1050 Komu, M., Schuetz, S., Stiemerling, M., and AG. Gurtov, 1051 "NAT Traversal for HIP", Internet 1052 Draft draft-ietf-hip-nat-traversal-02 (to appear), 1053 June 2007. 1055 [NATs-and-Overlays] 1056 Cooper, E. and P. Matthews, "The Effect of NATs on P2PSIP 1057 Overlay Architecture", Internet 1058 Draft draft-matthews-p2psip-nats-and-overlays, 1059 February 2007. 1061 [P2P-Arch] 1062 Shim, E., Narayanan, S., and G. Daley, "An Architecture 1063 for Peer-to-Peer Session Initiation Protocol (P2P SIP)", 1064 Internet Draft draft-shim-sipping-p2p-arch-00, 1065 February 2006. 1067 [P2PCommon] 1068 Baset, S. and H. Schulzrinne, "Peer-to-Peer Protocol 1069 (P2PP)", Internet Draft draft-baset-p2psip-p2pcommon-01 1070 (available at www.p2psip.org), February 2007. 1072 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1073 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 1074 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 1075 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 1076 Compression (ROHC): Framework and four profiles: RTP, UDP, 1077 ESP, and uncompressed", RFC 3095, July 2001. 1079 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors 1080 of Extensions to the Session Initiation Protocol (SIP)", 1081 RFC 4485, May 2006. 1083 [dSIP] Bryan, D., Lowekamp, B., and C. Jennings, "dSIP: A P2P 1084 Approach to SIP Registration and Resource Location", 1085 Internet Draft draft-bryan-p2psip-dsip-00, February 2007. 1087 Authors' Addresses 1089 Eric Cooper 1090 Avaya 1091 1135 Innovation Drive 1092 Ottawa, Ontario K2K 3G7 1093 Canada 1095 Phone: +1 613 592 4343 x228 1096 Email: ecooper@avaya.com 1098 Alan Johnston 1099 Avaya 1100 St. Louis, MO 63124 1101 USA 1103 Email: alan@sipstation.com 1105 Philip Matthews 1106 Avaya 1107 100 Innovation Drive 1108 Ottawa, Ontario K2K 3G7 1109 Canada 1111 Phone: +1 613 592 4343 x224 1112 Email: philip_matthews@magma.ca 1114 Full Copyright Statement 1116 Copyright (C) The IETF Trust (2007). 1118 This document is subject to the rights, licenses and restrictions 1119 contained in BCP 78, and except as set forth therein, the authors 1120 retain all their rights. 1122 This document and the information contained herein are provided on an 1123 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1124 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1125 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1126 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1127 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1128 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1130 Intellectual Property 1132 The IETF takes no position regarding the validity or scope of any 1133 Intellectual Property Rights or other rights that might be claimed to 1134 pertain to the implementation or use of the technology described in 1135 this document or the extent to which any license under such rights 1136 might or might not be available; nor does it represent that it has 1137 made any independent effort to identify any such rights. Information 1138 on the procedures with respect to rights in RFC documents can be 1139 found in BCP 78 and BCP 79. 1141 Copies of IPR disclosures made to the IETF Secretariat and any 1142 assurances of licenses to be made available, or the result of an 1143 attempt made to obtain a general license or permission for the use of 1144 such proprietary rights by implementers or users of this 1145 specification can be obtained from the IETF on-line IPR repository at 1146 http://www.ietf.org/ipr. 1148 The IETF invites any interested party to bring to its attention any 1149 copyrights, patents or patent applications, or other proprietary 1150 rights that may cover technology that may be required to implement 1151 this standard. Please address the information to the IETF at 1152 ietf-ipr@ietf.org. 1154 Acknowledgment 1156 Funding for the RFC Editor function is provided by the IETF 1157 Administrative Support Activity (IASA).