idnits 2.17.1 draft-petithuguenin-vipr-reload-usage-04.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 120 has weird spacing: '...ionType type;...' == Line 122 has weird spacing: '...ionData data;...' -- The document date (March 12, 2012) is 4428 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-20 == Outdated reference: A later version (-06) exists of draft-jennings-vipr-overview-02 ** Downref: Normative reference to an Informational draft: draft-jennings-vipr-overview (ref. 'VIPR-OVERVIEW') -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-05) exists of draft-petithuguenin-p2psip-access-control-04 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 VIPR M. Petit-Huguenin 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track J. Rosenberg 5 Expires: September 13, 2012 jdrosen.net 6 C. Jennings 7 Cisco 8 March 12, 2012 10 A Usage of Resource Location and Discovery (RELOAD) for Public Switched 11 Telephone Network (PSTN) Verification 12 draft-petithuguenin-vipr-reload-usage-04 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 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 13, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Registering an E.164 number . . . . . . . . . . . . . . . . . 3 59 4. Fetching a registration . . . . . . . . . . . . . . . . . . . 4 60 5. VIPR-REGISTRATION Kind Definition . . . . . . . . . . . . . . 5 61 6. Overlay Configuration Document Extension . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 8.1. Access Control Policies . . . . . . . . . . . . . . . . . 6 65 8.2. Application-ID . . . . . . . . . . . . . . . . . . . . . . 6 66 8.3. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.4. IETF XML Namespaces Registry . . . . . . . . . . . . . . . 7 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8 73 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . . 9 74 B.1. Modifications between vipr-04 and vipr-03 . . . . . . . . 9 75 B.2. Modifications between vipr-03 and vipr-02 . . . . . . . . 9 76 B.3. Modifications between vipr-02 and vipr-01 . . . . . . . . 9 77 B.4. Modifications between vipr-01 and vipr-00 . . . . . . . . 10 78 B.5. Modifications between vipr-00 and dispatch-03 . . . . . . 10 79 B.6. Modifications between dispatch-03 and dispatch-02 . . . . 10 80 B.7. Running Code Considerations . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 This document relies heavily on the concepts and terminology defined 86 in [VIPR-OVERVIEW] and will not make sense if you have not read that 87 document first. As it defines a usage for RELOAD [P2PSIP-BASE], it 88 assumes the reader is also familiar with that specification. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. Registering an E.164 number 98 To register an E.164 number a VIPR server stores a ViprRegistration 99 structure using the fully qualified E.164 based number without any 100 non-digit characters but the '+' character as Resource Name. 102 The contents of the ViprRegistration structure are as follow: 104 enum { reserved(0), node_id(8200), (65535) } ViprRegistrationType; 106 struct { 107 opaque name<0..2^8-1>; 108 } Method; 110 struct { 111 select (ViprRegistrationType) { 112 case node_id: 113 Destination pvp_provider<0..2^16-1>; 114 Method methods<0..2^16-1>; 116 /* This type can be extended */ 117 } ViprRegistrationData; 119 struct { 120 ViprRegistrationType type; 121 uint16 length; 122 ViprRegistrationData data; 123 } ViprRegistration; 125 The ViprRegistration structure contains the following values: 127 type 128 The type of the registration 130 length 131 The length of the data structure, i.e. not counting the type and 132 length fields 134 pvp_provider 135 A sequence of destinations to which an AppAttach request should be 136 sent to initiate the PVP protocol 138 methods 139 The set of methods that the PVP client can try to validate a PSTN 140 call to the E.164 number used as Resource Name. The format of the 141 method name is defined in [VIPR-PVP]. 143 The Node-ID used in the key MUST be ready to process AppAttach 144 requests for Application-ID 8470 at the time the registration is 145 done. 147 VIPR supports multiple registrations for a single E.164 number by 148 using a Dictionary Data Model. The dictionary key is the 149 concatenation of the Node-ID and the VServiceId, resulting in a 24 150 bytes long value. Using the Node-ID of the node performing the store 151 segments the keyspace of the dictionary so that no two peers ever 152 store using the same key. Using the VService allows for a single 153 VIPR server to service multiple clusters, and to ensure that numbers 154 published by one cluster (using one VServiceID) do not clobber or 155 step on numbers published by another cluster (using a different 156 VServiceID). 158 The Store operations are paced into the overlay at a fixed rate. The 159 VIPR server maintains a queue that is filled with store requests. 160 The VIPR server services that queue at a fixed, provisioned rate, 161 which is stored in a kind configuration variable named . 164 4. Fetching a registration 166 A VIPR server wishing to validate a E.164 number will start a Fetch 167 transaction using the fully qualified E.164 based number without any 168 non-digit characters but the '+' character as Resource Name. The 169 VIPR server will also retrieves the two replicas of the resource 170 record just retrieved. 172 The VIPR server will then inspects the elements in the 3 resource 173 record returned and will keep only the registrations that have the 174 same key in at least 2 of the 3 resource records returned. For each 175 registration kept, the VIPR server will fetch the certificates 176 associated with the Node-ID in the key using the CERTIFICATE_BY_NODE 177 usage and will verify that the signature of the registration is 178 valid. 180 The VIPR server can then send an AppAttach to the Node-ID found in 181 the key and registration, using the Application-ID 8470. After the 182 connection is established, the VIPR server can start PVP as specified 183 in [VIPR-PVP]. 185 5. VIPR-REGISTRATION Kind Definition 187 Name VIPR-REGISTRATION 189 Kind Ids The Resource Name for the VIPR-REGISTRATION Kind-ID is a 190 fully qualified E.164 based number without any non-digit 191 characters but the '+' character. The data stored is a 192 ViprRegistration, which contains the Node-ID of the peer to which 193 an AppAttach request should be sent to initiate the PVP protocol. 195 Data Model The data model for the VIPR Kind-ID is dictionary. The 196 dictionary key is the concatenation of the Node-ID and the 197 VServiceId, resulting in a 24 bytes long value. Using the Node-ID 198 of the node performing the store segments the keyspace of the 199 dictionary so that no two peers ever store using the same key and 200 using the VService allows for a single VIPR server to service 201 multiple clusters, and to ensure that numbers published by one 202 cluster (using one VServiceID) do not clobber or step on numbers 203 published by another cluster (using a different VServiceID). 205 Access Control The VIPR-MATCH policy can only be used with a VIPR- 206 REGISTRATION Kind-ID. In this policy, a given value MUST be 207 written (or overwritten) if and only if the first 16 bytes of the 208 dictionary key is equal to the Node-ID is indicated in the 209 SignerIdentity of the value. Note that VIPR always let the values 210 stored expire, so the exists field is always equal to TRUE. 212 Quota This kind MUST use the proportional quota algorithm described 213 in [RELOAD-QUOTA] by adding the element with a 214 value of "SIGNER" to the configuration file. A VIPR server MUST 215 provide enough Node-IDs to store all the E.164 numbers it is 216 responsible for by dividing this count by the value, 217 itself adjusted by an additional 3x factor to make sure that the 218 probability is low that a rejection occurs due to imperfect 219 distribution of Resource-IDs across the ring. 221 [[Open Issue: need to adjust the multiplier - basically birthday 222 problem!]] 224 The method for merging data after a partition follows the normal 225 RELOAD rules around temporal ordering. 227 6. Overlay Configuration Document Extension 229 This document extends the overlay configuration document by defining 230 a new element in the "urn:ietf:params:xml:ns:p2p:vipr" namespace. 232 The defines the maximum rate in seconds that a 233 VIPR server must use to execute Store requests. 235 The Compact Relax NG Grammar for this element is: 237 namespace vipr = "urn:ietf:params:xml:ns:p2p:vipr" 239 parameter &= element vipr:store-rate-limit { xsd:unsignedInt } 241 7. Security Considerations 243 TBD 245 8. IANA Considerations 247 8.1. Access Control Policies 249 This document adds a new access control policy to the "RELOAD Access 250 Control Policy" Registry: 252 +---------------+---------------+ 253 | Access-Policy | RFC | 254 +---------------+---------------+ 255 | VIPR-MATCH | This document | 256 +---------------+---------------+ 258 This access control policy was described in Section 5. 260 8.2. Application-ID 262 This document adds a new application ID to the "RELOAD 263 Application-ID" Registry: 265 +-------------+----------------+---------------+ 266 | Application | Application-ID | Specification | 267 +-------------+----------------+---------------+ 268 | PVP | 8470 | This document | 269 +-------------+----------------+---------------+ 271 This access control policy was described in Section 5. 273 8.3. Data Kind-ID 275 This document adds a new Data Kind-ID to the "RELOAD Data Kind-ID 276 Registry": 278 +-------------------+---------+---------------+ 279 | KIND | Kind-ID | RFC | 280 +-------------------+---------+---------------+ 281 | VIPR-REGISTRATION | 17 | This document | 282 +-------------------+---------+---------------+ 284 This Kind-ID was defined in Section 5. 286 8.4. IETF XML Namespaces Registry 288 This document adds the following URN to the "XML Namespaces" class of 289 the "IETF XML Registry": 291 urn:ietf:params:xml:ns:p2p:vipr 293 9. Acknowledgements 295 This document was improved by the input from the VIPR Design Team: 297 Mary Barnes 298 Daryl Malas 299 Hakim Mehmood 300 Muthu Arul Mozhi Perumal 301 Jon Peterson 302 Marc Petit-Huguenin 303 Michael Procter 304 John Ward 305 Dean Willis 307 This document was written with the xml2rfc tool described in 308 [RFC2629]. 310 10. References 311 10.1. Normative References 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, March 1997. 316 [P2PSIP-BASE] 317 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 318 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 319 Base Protocol", draft-ietf-p2psip-base-20 (work in 320 progress), January 2012. 322 [VIPR-OVERVIEW] 323 Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- 324 Huguenin, "Verification Involving PSTN Reachability: 325 Requirements and Architecture Overview", 326 draft-jennings-vipr-overview-02 (work in progress), 327 September 2011. 329 [VIPR-PVP] 330 Petit-Huguenin, M., Rosenberg, J., and C. Jennings, "The 331 Public Switched Telephone Network (PSTN) Validation 332 Protocol (PVP)", draft-petithuguenin-vipr-pvp-04 (work in 333 progress), March 2012. 335 [RELOAD-QUOTA] 336 Petit-Huguenin, M., Rosenberg, J., and C. Jennings, 337 "Proportional Quota in REsource LOcation And Discovery 338 (RELOAD)", draft-petithuguenin-vipr-proportional-quota-00 339 (work in progress), October 2011. 341 10.2. Informative References 343 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 344 June 1999. 346 [ACCESS-CONTROL] 347 Petit-Huguenin, M., "Configuration of Access Control 348 Policy in REsource LOcation And Discovery (RELOAD) Base 349 Protocol", draft-petithuguenin-p2psip-access-control-04 350 (work in progress), October 2011. 352 Appendix A. Examples 354 The Resource Name and Resource-ID for the E.164 number +1 408 555 355 5432 are: 357 +---------------+---------------------------------+ 358 | Resource Name | Resource-ID | 359 +---------------+---------------------------------+ 360 | +14085555432 | 6abaec4308294521e2f600ab5fd01e5 | 361 +---------------+---------------------------------+ 363 The VIPR-MATCH access control can be implemented with the following 364 code (Using the notation in [ACCESS-CONTROL]): 366 var equals = function(a, b) { 367 if (a.length !== b.length) return false; 368 for (var i = 0; i < a.length; i++) { 369 if (a[i] !== b[i]) return false; 370 } 371 return true; 372 }; 373 var length = configuration.node_id_length; 374 return equals(entry.key.slice(0, length), signature.node_id); 376 Appendix B. Release notes 378 This section must be removed before publication as an RFC. 380 B.1. Modifications between vipr-04 and vipr-03 382 o The ViprRegistration record now contains a destination list 383 instead of a Node-ID. 385 B.2. Modifications between vipr-03 and vipr-02 387 o The E.164 number is no longer stored 3 times. 388 o Moved the parameter under the 389 element. 390 o The VIPR registration now also contains the list of supported PVP 391 methods. 393 B.3. Modifications between vipr-02 and vipr-01 395 o Made clear in the access control policy that exists is always 396 equal to TRUE. 397 o Updated with new version of proportional-quota. 398 o The access control code now uses the configuration parameter. 399 o Assigned values to Application-ID and Kind-ID. 400 o Added running code section. 402 o Nits 404 B.4. Modifications between vipr-01 and vipr-00 406 o Moved most of the quota algorithm to a separate I-D named 407 draft-petithuguenin-p2psip-proportional-quota. 408 o Removed the text saying that the same DHT can also be used for a 409 RELOAD SIP usage, as it contradicts text in overview. Also the 410 quota algorithm does not work with clients, but SIP registration 411 uses clients. 412 o Added Terminology section 413 o Converted the TLV value stored to a structure using the syntax 414 described in p2psip-base to not be dependent on VAP. The new 415 structure is bit compatible with the old definition. 416 o Changed the dictionary key to be binary based instead of text 417 based. 418 o Copied text from VAP explaining that the Store operations are 419 queued and that the rate is limited. 420 o Added voting algorithm when fetch returns different results for 421 the 3 copies. 422 o Added explanation on how to verify the signatures. 423 o Added text on how to form the PVP connection 424 o Rewrote some of the text so it looks more like a regular RELOAD 425 usage. 426 o Removed section 3 "PeerID Shim" now that support for multiple 427 Node-ID in certificates in fully integrated in RELOAD base. 428 o Filled IANA section 429 o Added examples of conversion from E.164 number to Resource-ID 430 o Added example code for the VIPR access control 432 B.5. Modifications between vipr-00 and dispatch-03 434 o Moved to new Working Group. 436 B.6. Modifications between dispatch-03 and dispatch-02 438 o Nits. 439 o Shorter I-Ds references. 440 o Fixed the peerID and VServiceID to be hexadecimal. 441 o Fixed the description of the dictionary entry 442 o Fixed the description of the TLV. 443 o Used +1 408 555 prefix for phone numbers in examples. 444 o Replaced peerId by Node-ID 445 o Replaced resourceID by Resource-ID 447 B.7. Running Code Considerations 449 o Reference Implementation for the kind and access control policy 450 (). 451 Marc Petit-Huguenin. Implements version -02. 453 Authors' Addresses 455 Marc Petit-Huguenin 456 Unaffiliated 458 Email: petithug@acm.org 460 Jonathan Rosenberg 461 jdrosen.net 462 Monmouth, NJ 463 US 465 Email: jdrosen@jdrosen.net 466 URI: http://www.jdrosen.net 468 Cullen Jennings 469 Cisco 470 170 West Tasman Drive 471 San Jose, CA 95134 472 USA 474 Phone: +1 408 421-9990 475 Email: fluffy@cisco.com