idnits 2.17.1 draft-rosenberg-dispatch-vipr-reload-usage-03.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 25, 2010) is 4930 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 (-26) exists of draft-ietf-p2psip-base-11 == Outdated reference: A later version (-21) exists of draft-ietf-p2psip-sip-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dispatch J.R. Rosenberg 3 Internet-Draft jdrosen.net 4 Intended status: Standards Track C. Jennings 5 Expires: April 28, 2011 Cisco 6 M. Petit-Huguenin 7 Stonyfish 8 October 25, 2010 10 A Usage of Resource Location and Discovery (RELOAD) for Public Switched 11 Telephone Network (PSTN) Verification 12 draft-rosenberg-dispatch-vipr-reload-usage-03 14 Abstract 16 Verification Involving PSTN Reachability (ViPR) is a technique for 17 inter-domain SIP federation. ViPR makes use of the RELOAD protocol 18 to store unverified mappings from phone numbers to RELOAD nodes, with 19 whom a validation process can be run. This document defines the 20 usage of RELOAD for this purpose. 22 Legal 24 This documents and the information contained therein are provided on 25 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 26 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 27 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 28 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 29 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 30 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 31 FOR A PARTICULAR PURPOSE. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 28, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. ViPR Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. PeerID Shim . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 74 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 75 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 6 76 A.1. Modifications between rosenberg-03 and rosenberg-02 . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 This document relies heavily on the concepts and terminology defined 82 in [VIPR-OVERVIEW] and will not make sense if you have not read that 83 document first. As it defines a usage for RELOAD [P2PSIP-BASE], it 84 assumes the reader is also familiar with that specification. The 85 same DHT can also be used for a RELOAD SIP usage [P2PSIP-SIP]. 87 2. ViPR Usage 89 The ViPR usage defines details for how the DHT is used for ViPR 90 operations. 92 The ViPR usage defines Kind-ID 0x00000001. This Kind-ID is a 93 dictionary entry. Its Resource-ID is defined through a 94 transformation which takes an E.164 based number, and computes a 95 Resource-ID as the least significant 128 bits of the SHA1 hash of the 96 following string: Cat(CHOICE(null, "COPY", "COPY2"), number) That 97 is, the Resource-ID is the hash of a string which is the 98 concatenation of the number, prefixed with nothing, or the words 99 "COPY1" or "COPY2". 101 For example, for number +14085555432: 103 Resource-ID = least128(SHA1("+14085555432")) 105 or 107 Resource-ID = least128(SHA1("COPY1+14085555432")) 109 or 111 Resource-ID = least128(SHA1("COPY2+14085555432")) 113 The object stored at this resource ID is a dictionary entry, which 114 has a key and a value: 116 Object = {key,value} 118 Here, the key is formed by taking the Node-ID of the storing node in 119 hex format, without the "0x", appending a "+", followed by the 120 VServiceID in hex format, without the "0x". For example, if a peer 121 with Node-ID 123 0x8f60f5eab753037e64ab6c53947fd532 125 receives a Publish with a VServiceID of 126 0x7eeb6a7036478351 128 The resulting key is: 130 8f60f5eab753037e64ab6c53947fd532+7eeb6a7036478351 132 Both parts of this key are important. Using the Node-ID of the node 133 performing the store basically segments the keyspace of the 134 dictionary so that no two peers ever store using the same key. 135 Indeed, the responsible node will verify the signature over the 136 stored data and check the Node-ID against the value of the key, to 137 make sure that a conflict does not take place. The usage of the 138 VService allows for a single ViPR server to service multiple 139 clusters, and to ensure that numbers published by one cluster (using 140 one VServiceID) do not clobber or step on numbers published by 141 another cluster (using a different VServiceID). The responsible node 142 does not verify or check the VServiceID. 144 When a node receives a Store operation for this usage, the data 145 itself has a signature. The node responsible for storing the data 146 must verify this signature; the certificate will always be included 147 in the data and indicate which Node-ID is used. The responsible node 148 must check that this Node-ID is included in the cert. If the 149 signature verifies, the responsible node checks that the data model 150 is a dictionary entry. The key must meet the format above. The 151 responsible node must check that it is a 32 character sequence of 152 numbers and letters a-f, followed by a +, followed by a 16 character 153 sequence of numbers and letters a-f. If this checks, the key is 154 split in half along the plus. The first 32 characters are considered 155 a hex value and compared with the Node-ID used for the signature. If 156 they match, it is good. Otherwise the Store operation is rejected. 157 If they did match, next the responsible node checks the value. It 158 must be a TLV, with the same format used by VAP, and it must contain 159 a single Node-ID attribute. The Node-ID must match that used for the 160 signature. If they don't match, the Store operation is rejected. If 161 they do match, the next step is a quota check. 163 For each peer that the responsible node is storing data for, it must 164 maintain a count of the number of unique dictionary entries being 165 stored for that Node-ID. For each resourceID, each key constitutes a 166 unique dictionary entry. So if a peer is storing 5 resourceIDs, and 167 at each of those 5, there are two keys whose first 32 bits correspond 168 to a particular Node-ID, it means this node is currently storing 10 169 unique dictionary entries for that Node-ID. 171 It takes the StorageQuota configuration parameter for this DHT, which 172 measures the amount of numbers a particular node can store. That 173 value is multiplied by nine (a 3x factor to account for the 174 application-layer copies (COPY1 and COPY2), and another 3x factor for 175 replicas). Then, an addition 3x factor is added for rounding to make 176 sure that the probability is low that a rejection occurs due to 177 imperfect distribution of resourceIDs across the ring. (Open Issue: 178 need to adjust this multiplier - basically birthday problem!) and 179 then divided by the fraction of the hashspace owned by this ViPR 180 server. If the result is less than one, it is rounded up to two. 181 This is the max number of unique entries that can be stored for this 182 storing peer ID. If the ViPR server is not yet storing this many 183 entries for that peer ID, the store is allowed. 185 The method for merging data after a partition follows the normal 186 RELOAD rules around temporal ordering. 188 3. PeerID Shim 190 Because the ViPR implementation of RELOAD protocol makes use of the 191 concept of multiple Node-ID on the same physical box, utilizing a 192 single cert, the TLS handshakes alone are not sufficient to determine 193 the entity on both sides of the TLS connection. As such, we will 194 have a small "shim" type of protocol, which runs after TLS, but is 195 not formally part of RELOAD. 197 When a node initiates a TLS connection towards another node, after 198 the TLS completes, it sends this message. The message contains the 199 Node-ID associated with this connection. The recipient gets this, 200 and sends back a similar message, containing its Node-ID. Both sides 201 will verify that, the Node-ID sent by the other side, are amongst the 202 Node-IDs listed in the certificate. The connections are then stored 203 in the connection tables, indexed by this Node-ID. 205 Furthermore, if, after this exchange, a node determines that it 206 already has a connection in its connection table with that Node-ID on 207 the far side, the older connection is closed. This is actually a 208 critical security function! Without this, a user could clone ViPR 209 servers utilizing the same certs, and each one can join the network. 211 Finally, once the exchange has taken place, the node compares the 212 Node-ID from its peer with the current set of blacklisted Node-ID 213 from the ACL that is distributed through the DHT. If the remote 214 Node-ID appears on the list, the node closes the TCP/TLS connection 215 immediately. 217 The reason we are using a non-reload message for this, is that we 218 need to be 100% sure that this never propagates. It is strictly over 219 a single connection and should never be routed. Indeed, had we not 220 had this idea of multiple Node-ID in a single cert, this would have 221 effectively been accomplished through TLS. Alternatively, there is a 222 TLS command for telling the other side who I expect them to be; 223 however this is not implemented in older versions of OpenSSL, and so 224 our shim forms an alternative to that which can be run on top of 225 OpenSSL. 227 4. Security Considerations 229 TBD 231 5. IANA Considerations 233 TBD. Need to register items in IANA registries created by RELOAD. 235 6. References 237 6.1. Normative References 239 [P2PSIP-BASE] 240 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 241 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 242 Base Protocol", draft-ietf-p2psip-base-11 (work in 243 progress), October 2010. 245 [VIPR-OVERVIEW] 246 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, 247 "Verification Involving PSTN Reachability: Requirements 248 and Architecture Overview", 249 draft-rosenberg-dispatch-vipr-overview-04 (work in 250 progress), October 2010. 252 6.2. Informative References 254 [P2PSIP-SIP] 255 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 256 H. Schulzrinne, "A SIP Usage for RELOAD", 257 draft-ietf-p2psip-sip-05 (work in progress), July 2010. 259 Appendix A. Release notes 261 This section must be removed before publication as an RFC. 263 A.1. Modifications between rosenberg-03 and rosenberg-02 265 o Nits. 266 o Shorter I-Ds references. 267 o Fixed the peerID and VServiceID to be hexadecimal. 268 o Fixed the description of the dictionary entry 269 o Fixed the description of the TLV. 270 o Used +1 408 555 prefix for phone numbers in examples. 271 o Replaced peerId by Node-ID 272 o Replaced resourceID by Resource-ID 274 Authors' Addresses 276 Jonathan Rosenberg 277 jdrosen.net 278 Monmouth, NJ 279 US 281 Email: jdrosen@jdrosen.net 282 URI: http://www.jdrosen.net 284 Cullen Jennings 285 Cisco 286 170 West Tasman Drive 287 San Jose, CA 95134 288 USA 290 Phone: +1 408 421-9990 291 Email: fluffy@cisco.com 293 Marc Petit-Huguenin 294 Stonyfish 296 Email: marc@stonyfish.com