idnits 2.17.1 draft-petithuguenin-vipr-reload-usage-02.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 == Line 127 has weird spacing: '...ionType type;...' == Line 129 has weird spacing: '...ionData data;...' -- The document date (July 10, 2011) is 4672 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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-16 == Outdated reference: A later version (-06) exists of draft-jennings-vipr-overview-00 ** Downref: Normative reference to an Informational draft: draft-jennings-vipr-overview (ref. 'VIPR-OVERVIEW') == Outdated reference: A later version (-04) exists of draft-petithuguenin-vipr-pvp-01 == Outdated reference: A later version (-05) exists of draft-petithuguenin-p2psip-access-control-03 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 VIPR J. Rosenberg 3 Internet-Draft jdrosen.net 4 Intended status: Standards Track C. Jennings 5 Expires: January 11, 2012 Cisco 6 M. Petit-Huguenin 7 Stonyfish 8 July 10, 2011 10 A Usage of Resource Location and Discovery (RELOAD) for Public Switched 11 Telephone Network (PSTN) Verification 12 draft-petithuguenin-vipr-reload-usage-02 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 January 11, 2012. 50 Copyright Notice 52 Copyright (c) 2011 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Registering an E.164 number . . . . . . . . . . . . . . . . . 3 70 4. Fetching a registration . . . . . . . . . . . . . . . . . . . 4 71 5. VIPR-REGISTRATION Kind Definition . . . . . . . . . . . . . . 5 72 6. Overlay Configuration Document Extension . . . . . . . . . . . 6 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 75 8.1. Access Control Policies . . . . . . . . . . . . . . . . . 6 76 8.2. Application-ID . . . . . . . . . . . . . . . . . . . . . . 7 77 8.3. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . . 7 78 8.4. IETF XML Namespaces Registry . . . . . . . . . . . . . . . 7 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 82 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8 83 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . . 9 84 B.1. Modifications between vipr-02 and vipr-01 . . . . . . . . 9 85 B.2. Modifications between vipr-01 and vipr-00 . . . . . . . . 9 86 B.3. Modifications between vipr-00 and dispatch-03 . . . . . . 10 87 B.4. Modifications between dispatch-03 and dispatch-02 . . . . 10 88 B.5. Running Code Considerations . . . . . . . . . . . . . . . 10 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 91 1. Introduction 93 This document relies heavily on the concepts and terminology defined 94 in [VIPR-OVERVIEW] and will not make sense if you have not read that 95 document first. As it defines a usage for RELOAD [P2PSIP-BASE], it 96 assumes the reader is also familiar with that specification. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Registering an E.164 number 106 To register an E.164 number a VIPR server stores a ViprRegistration 107 structure using the fully qualified E.164 based number without any 108 non-digit characters but the '+' character as Resource Name. For 109 redundancy purpose, the VIPR server MUST store the same 110 ViprRegistration structure two more times by using the same Resource 111 Name prepended with the "COPY1" and "COPY2" character string 112 respectively. 114 The contents of the ViprRegistration structure are as follow: 116 enum { reserved(0), node_id(8200), (65535) } ViprRegistrationType; 118 struct { 119 select (ViprRegistrationType) { 120 case node_id: 121 NodeId pvp_provider; 123 /* This type can be extended */ 124 } ViprRegistrationData; 126 struct { 127 ViprRegistrationType type; 128 uint16 length; 129 ViprRegistrationData data; 130 } ViprRegistration; 132 The ViprRegistration structure contains the following values: 134 type 135 The type of the registration 137 length 138 The length of the data structure, i.e. not counting the type and 139 length fields 141 pvp_provider 142 The Node-ID of the peer to which an AppAttach request should be 143 sent to initiate the PVP protocol 145 The Node-ID used in the pvp_provider field and in the key MUST be 146 ready to process AppAttach requests for Application-ID 8470 at the 147 time the registration is done. 149 VIPR supports multiple registrations for a single E.164 number by 150 using a Dictionary Data Model. The dictionary key is the 151 concatenation of the Node-ID and the VServiceId, resulting in a 24 152 bytes long value. Using the Node-ID of the node performing the store 153 segments the keyspace of the dictionary so that no two peers ever 154 store using the same key. Using the VService allows for a single 155 VIPR server to service multiple clusters, and to ensure that numbers 156 published by one cluster (using one VServiceID) do not clobber or 157 step on numbers published by another cluster (using a different 158 VServiceID). 160 The Store operations are paced into the overlay at a fixed rate. The 161 VIPR server maintains a queue that is filled with store requests. 162 The VIPR server services that queue at a fixed, provisioned rate, 163 which is stored in a kind configuration variable named . 166 4. Fetching a registration 168 A VIPR server wishing to validate a E.164 number will start 3 Fetch 169 transactions using respectivelly the fully qualified E.164 based 170 number without any non-digit characters but the '+' character as 171 Resource Name, the same Resource Name prepended with the "COPY1" 172 character string and finally the same Resource Name prepended with 173 the "COPY2" character string. 175 The VIPR server will then inspects the elements in the 3 dictionary 176 returned and will keep only the registrations that have the same key 177 in at least 2 of the 3 dictionary returned. For each registration 178 kept, the VIPR server will fetch the certificates associated with the 179 Node-ID in the key using the CERTIFICATE_BY_NODE usage and will 180 verify that the signature of the registration is valid. 182 The VIPR server can then send an AppAttach to the Node-ID found in 183 the key and registration, using the Application-ID 8470. After the 184 connection is established, the VIPR server can start PVP as specified 185 in [VIPR-PVP]. 187 5. VIPR-REGISTRATION Kind Definition 189 Name VIPR-REGISTRATION 191 Kind Ids The Resource Name for the VIPR-REGISTRATION Kind-ID is a 192 fully qualified E.164 based number without any non-digit 193 characters but the '+' character, prepended by either an empty 194 character string, the "COPY1" character string or the "COPY2" 195 character string. The data stored is a ViprRegistration, which 196 contains the Node-ID of the peer to which an AppAttach request 197 should be sent to initiate the PVP protocol. 199 Data Model The data model for the VIPR Kind-ID is dictionary. The 200 dictionary key is the concatenation of the Node-ID and the 201 VServiceId, resulting in a 24 bytes long value. Using the Node-ID 202 of the node performing the store segments the keyspace of the 203 dictionary so that no two peers ever store using the same key and 204 using the VService allows for a single VIPR server to service 205 multiple clusters, and to ensure that numbers published by one 206 cluster (using one VServiceID) do not clobber or step on numbers 207 published by another cluster (using a different VServiceID). 209 Access Control The VIPR-MATCH policy can only be used with a VIPR- 210 REGISTRATION Kind-ID. In this policy, a given value MUST be 211 written (or overwritten) if and only if the Node-ID in the 212 pvp_provider field of the ViprRegistration structure is equal to 213 the first 16 bytes of the dictionary key and if the same Node-ID 214 is the one indicated in the SignerIdentity of the value. Note 215 that VIPR always let the values stored expire, so the exists field 216 is always equal to TRUE. 218 Quota This kind MUST use the proportional quota algorithm described 219 in [RELOAD-QUOTA] by adding the element with a 220 value of "SIGNER" to the configuration file. The 221 value, which measures the amount of E.164 numbers a particular 222 node can store, MUST be adjusted to account for the application- 223 layer copies (COPY1 and COPY2). A VIPR server MUST provide enough 224 Node-IDs to store all the E.164 numbers it is responsible for by 225 dividing this count by the value, itself adjusted by 226 an additional 3x factor to make sure that the probability is low 227 that a rejection occurs due to imperfect distribution of Resource- 228 IDs across the ring. 230 [[Open Issue: need to adjust the multiplier - basically birthday 231 problem!]] 233 The method for merging data after a partition follows the normal 234 RELOAD rules around temporal ordering. 236 6. Overlay Configuration Document Extension 238 This document extends the overlay configuration document by defining 239 a new element in the "urn:ietf:params:xml:ns:p2p:vipr" namespace. 241 The defines the maximum rate in seconds that a 242 VIPR server must use to execute Store requests. 244 The Compact Relax NG Grammar for this element is: 246 namespace vipr = "urn:ietf:params:xml:ns:p2p:vipr" 248 kind-parameter &= element vipr:store-rate-limit { xsd:unsignedInt } 250 7. Security Considerations 252 TBD 254 8. IANA Considerations 256 8.1. Access Control Policies 258 This document adds a new access control policy to the "RELOAD Access 259 Control Policy" Registry: 261 +---------------+---------------+ 262 | Access-Policy | RFC | 263 +---------------+---------------+ 264 | VIPR-MATCH | This document | 265 +---------------+---------------+ 267 This access control policy was described in Section 5. 269 8.2. Application-ID 271 This document adds a new application ID to the "RELOAD 272 Application-ID" Registry: 274 +-------------+----------------+---------------+ 275 | Application | Application-ID | Specification | 276 +-------------+----------------+---------------+ 277 | PVP | 8470 | This document | 278 +-------------+----------------+---------------+ 280 This access control policy was described in Section 5. 282 8.3. Data Kind-ID 284 This document adds a new Data Kind-ID to the "RELOAD Data Kind-ID 285 Registry": 287 +-------------------+---------+---------------+ 288 | KIND | Kind-ID | RFC | 289 +-------------------+---------+---------------+ 290 | VIPR-REGISTRATION | 17 | This document | 291 +-------------------+---------+---------------+ 293 This Kind-ID was defined in Section 5. 295 8.4. IETF XML Namespaces Registry 297 This document adds the following URN to the "XML Namespaces" class of 298 the "IETF XML Registry": 300 urn:ietf:params:xml:ns:p2p:vipr 302 9. References 304 9.1. Normative References 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, March 1997. 309 [P2PSIP-BASE] 310 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 311 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 312 Base Protocol", draft-ietf-p2psip-base-16 (work in 313 progress), July 2011. 315 [VIPR-OVERVIEW] 316 Jennings, C., Rosenberg, J., and M. Petit-Huguenin, 317 "Verification Involving PSTN Reachability: Requirements 318 and Architecture Overview", 319 draft-jennings-vipr-overview-00 (work in progress), 320 April 2011. 322 [VIPR-PVP] 323 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, "The 324 Public Switched Telephone Network (PSTN) Validation 325 Protocol (PVP)", draft-petithuguenin-vipr-pvp-01 (work in 326 progress), June 2011. 328 [RELOAD-QUOTA] 329 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, 330 "Proportional Quota in REsource LOcation And Discovery 331 (RELOAD)", 332 draft-petithuguenin-p2psip-proportional-quota-01 (work in 333 progress), July 2011. 335 9.2. Informative References 337 [ACCESS-CONTROL] 338 Petit-Huguenin, M., "Configuration of Access Control 339 Policy in REsource LOcation And Discovery (RELOAD) Base 340 Protocol", draft-petithuguenin-p2psip-access-control-03 341 (work in progress), July 2011. 343 Appendix A. Examples 345 The Resource Names and Resource-IDs for the E.164 number +1 408 555 346 5432 are: 348 +-------------------+---------------------------------+ 349 | Resource Name | Resource-ID | 350 +-------------------+---------------------------------+ 351 | +14085555432 | 6abaec4308294521e2f600ab5fd01e5 | 352 | COPY1+14085555432 | 9038006a8de78f818d318b60ed149d9 | 353 | COPY2+14085555432 | 3d288c777bcf3aad38b077355026718 | 354 +-------------------+---------------------------------+ 356 The VIPR-MATCH access control can be implemented with the following 357 code (Using the notation in [ACCESS-CONTROL]): 359 var equals = function(a, b) { 360 if (a.length !== b.length) return false; 361 for (var i = 0; i < a.length; i++) { 362 if (a[i] !== b[i]) return false; 363 } 364 return true; 365 }; 366 var length = configuration.node_id_length; 367 return equals(entry.key.slice(0, length), 368 entry.value.slice(4, length + 4)) 369 && equals(entry.key.slice(0, length), signature.node_id); 371 Appendix B. Release notes 373 This section must be removed before publication as an RFC. 375 B.1. Modifications between vipr-02 and vipr-01 377 o Made clear in the access control policy that exists is always 378 equal to TRUE. 379 o Updated with new version of proportional-quota. 380 o The access control code now uses the configuration parameter. 381 o Assigned values to Application-ID and Kind-ID. 382 o Added running code section. 383 o Nits 385 B.2. Modifications between vipr-01 and vipr-00 387 o Moved most of the quota algorithm to a separate I-D named 388 draft-petithuguenin-p2psip-proportional-quota. 389 o Removed the text saying that the same DHT can also be used for a 390 RELOAD SIP usage, as it contradicts text in overview. Also the 391 quota algorithm does not work with clients, but SIP registration 392 uses clients. 393 o Added Terminology section 394 o Converted the TLV value stored to a structure using the syntax 395 described in p2psip-base to not be dependent on VAP. The new 396 structure is bit compatible with the old definition. 397 o Changed the dictionary key to be binary based instead of text 398 based. 399 o Copied text from VAP explaining that the Store operations are 400 queued and that the rate is limited. 401 o Added voting algorithm when fetch returns different results for 402 the 3 copies. 403 o Added explanation on how to verify the signatures. 405 o Added text on how to form the PVP connection 406 o Rewrote some of the text so it looks more like a regular RELOAD 407 usage. 408 o Removed section 3 "PeerID Shim" now that support for multiple 409 Node-ID in certificates in fully integrated in RELOAD base. 410 o Filled IANA section 411 o Added examples of conversion from E.164 number to Resource-ID 412 o Added example code for the VIPR access control 414 B.3. Modifications between vipr-00 and dispatch-03 416 o Moved to new Working Group. 418 B.4. Modifications between dispatch-03 and dispatch-02 420 o Nits. 421 o Shorter I-Ds references. 422 o Fixed the peerID and VServiceID to be hexadecimal. 423 o Fixed the description of the dictionary entry 424 o Fixed the description of the TLV. 425 o Used +1 408 555 prefix for phone numbers in examples. 426 o Replaced peerId by Node-ID 427 o Replaced resourceID by Resource-ID 429 B.5. Running Code Considerations 431 o Reference Implementation for the kind and access control policy 432 (). 433 Marc Petit-Huguenin. Implements version -02. 435 Authors' Addresses 437 Jonathan Rosenberg 438 jdrosen.net 439 Monmouth, NJ 440 US 442 Email: jdrosen@jdrosen.net 443 URI: http://www.jdrosen.net 444 Cullen Jennings 445 Cisco 446 170 West Tasman Drive 447 San Jose, CA 95134 448 USA 450 Phone: +1 408 421-9990 451 Email: fluffy@cisco.com 453 Marc Petit-Huguenin 454 Stonyfish 456 Email: marc@stonyfish.com