idnits 2.17.1 draft-pierce-ieprep-assured-service-arch-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 150 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([Pierce1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 2004) is 7196 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) == Unused Reference: 'RFC3313' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC3325' is defined on line 350, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3313 ** Downref: Normative reference to an Informational RFC: RFC 3325 -- Possible downref: Normative reference to a draft: ref. 'Pierce1' == Outdated reference: A later version (-10) exists of draft-ietf-sip-resource-priority-00 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Mike Pierce 3 Internet Draft Artel 4 draft-pierce-ieprep-assured-service-arch-02.txt Don Choi 5 January 2004 DISA 6 Expires July 2004 8 Architecture for Assured Service Capabilities in Voice over IP 9 draft-pierce-ieprep-assured-service-arch-02.txt 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Copyright 34 Copyright (C) Internet Society 2004. All rights reserved. 35 Reproduction or translation of the complete document, but not of 36 extracts, including this notice, is freely permitted. 38 Abstract 40 Assured Service refers to the set of capabilities used to ensure 41 that mission critical communications are setup and remain connected. 42 This memo describes the architecture required to meet the 43 requirements detailed in [Pierce1]. 45 0. History..........................................................2 46 1. Introduction.....................................................2 47 2. Architectures....................................................3 48 2.1. End-to-end Architecture.......................................3 49 2.2. Service Provider Network Architecture.........................3 50 3. Required Architecture............................................4 51 4. Required Procedures..............................................6 52 4.1. Authentication................................................6 53 4.2. Function of Proxy.............................................6 54 4.3. Function of the Access Router.................................7 55 4.4. Session Control...............................................7 56 5. Security Considerations..........................................7 57 6. References.......................................................8 58 7. Authors' Addresses...............................................8 60 0. History 62 This draft was originally submitted under SIPPING. This revision is 63 being submitted under IEPREP to be included in the discussions for 64 related services such as IEPS. 66 (SIPPING) -00: Original 68 (IEPREP) -00: Added Access Router to architecture required to 69 support Assured Service. 71 -01 Updated references 73 -02 Updated references and minor editorial changes. 75 1. Introduction 77 The requirements for Assured Service are given in [Pierce1]. Many 78 other drafts and RFCs have addressed the assumed architecture for 79 the provision of SIP-based services. A lot of consideration has been 80 given to continued reliance on the pure peer-to-peer model on which 81 the Internet (and especially HTTP) has been based vs. migration to 82 centralized control models in which dedicated proxies perform 83 specific functions for the control of telephony services. This would 84 include, possibly, full knowledge of the state of each call. 86 While there is an wide-spread desire expressed in various IETF 87 discussions to maintain (or return to) the pure peer-to-peer 88 architecture, there has been increasing admissions in various drafts 89 that centralized control or intelligent "middleboxes" are required 90 in many cases. Some examples are: 92 1. RFC 3261 defines the notion of a "Call Stateful proxy", which 93 "retains state for a dialog from the initiating INVITE to the 94 terminating BYE request", i.e., for the duration of a call. However, 95 no use of this state has been included in the current version of SIP 96 2. Draft-ietf-sipping-cc-framework-02 included the concept of a 97 "central control" signaling model. 99 3. The abstract for draft-ietf-sipping-service-examples-05 100 recognizes that "some [services] require the assistance of a SIP 101 Proxy", and it states that the flows shown assume "a network of 102 proxies, registrars, PSTN gateways, and other SIP servers that have 103 a pre-established trust relationship with each other... User agents 104 wishing to use the services in this network are required to 105 authenticate themselves with an edge proxy...". 107 4. RFC 3325 for identity and privacy is based fully on use of a 108 network of trusted SIP servers. It states that "these mechanisms 109 provide no means by which end users can securely share identity 110 information end-to-end without a trusted service provider." 112 2. Architectures 114 Various discussions and memos have identified two potential network 115 architectures for the provision of SIP services. They are briefly: 117 2.1. End-to-end Architecture 119 All service provision is between and under control of the calling 120 and called party, referred to as "User Agent Client (UAC)" and "User 121 Agent Server (UAS)", respectively. This terminology of "client" and 122 "server" are based on the HTTP model from which this model is 123 derived and have no real significance to this model. Either end can 124 initiate a transaction. There is no device in-between which provides 125 service support, only routers for packets. Other required devices 126 (address translation, etc.) which the calling user must access are 127 simply additional UAS's. 129 There is no "Service Provider" for the voice service, only a 130 provider of the packet switched infrastructure. 132 2.2. Service Provider Network Architecture 134 A Service Provider maintains and controls network elements which 135 play an active role in the provision of services to end users. These 136 network elements may be referred to as back-to-back user agents 137 (B2BUA), proxies, servers, middleboxes, or intermediaries but they 138 all have the common characteristic of being provided by a trusted 139 Service Provider and they provide an important logical function 140 between the end users. These elements terminate SIP messages, 141 perform service control, and send new or modified SIP messages to 142 other network elements or to the other user. The result is that no 143 SIP message goes directly from one UA to the other (unless 144 specifically authorized by the control element). 146 The "Service Provider" may be the same company or entity which 148 3. Required Architecture 150 In order to provide the security and feature control required for 151 Assured Service as defined in [Pierce1], it is necessary to utilize 152 the Service Provider Network Architecture in which proxies are used 153 to support call origination and termination for each user involved 154 in the service. The architecture is the "trapezoid" described in SIP 155 [RFC3261] as follows (figure actually copied from RFC 3263): 157 ............................ .............................. 158 . . . . 159 . +-------+ . . +-------+ . 160 . | | . . | | . 161 . | Proxy |------------- | Proxy | . 162 . | 1 | . . | 2 | . 163 . | | . . | | . 164 . / +-------+ . . +-------+ \ . 165 . / . . \ . 166 . / . . \ . 167 . / . . \ . 168 . / . . \ . 169 . / . . \ . 170 . / . . \ . 171 . / . . \ . 172 . +-------+ . . +-------+ . 173 . | | . . | | . 174 . | | . . | | . 175 . | UA 1 | . . | UA 2 | . 176 . | | . . | | . 177 . +-------+ . . +-------+ . 178 . Domain A . . Domain B . 179 ............................ .............................. 181 Interfaces: 183 (1) Originating UA 1 to Proxy 1: Authentication and all SIP messages 184 to/from UA 1 185 (2) Proxy 1 to Proxy 2 (and to other devices such as policy 186 servers): SIP messages and policy actions 187 (3) Proxy 2 to terminating UA 2: Authentication and all SIP messages 188 to/from U 2 189 (4) Originating UA 1 to terminating UA 2: Voice packets, no 190 signaling messages 192 However, the above architecture requires the addition of another 193 component to provide control of the user's data packets (voice) in 194 the Assured Service case. This is important since the packets 195 themselves need to be marked for preferential treatment, including 196 the ability to get "priority" over the packet transfer of another 197 user. 199 the local network and the core network. This may be between the 200 Ethernet LAN and the IP "cloud" or it may be between the locally 201 controlled IP network and the global IP network. In any case, its 202 function is to regulate the transport of priority marked packets 203 into the core. 205 The following figure depicts this architecture: 207 ............................. .............................. 208 . . . . 209 . +-------+ . . +-------+ . 210 . | | . (2) . | | . 211 . | Proxy |------------------------ | Proxy | . 212 . | 1 | . . | 2 | . 213 . | | . . | | . 214 . +-------+ . . +-------+ . 215 . / \ . . / \ . 216 . (1) / \ (1a) . . (3a) / \ (3) . 217 . / \ . . / \ . 218 . / \ . . / \ . 219 . +-------+ +----+ . . +----+ +-------+ . 220 . | | (4a) | AR | . (4b) . | AR | (4c) | | . 221 . | UA 1 |------>| 1 |---------------->| 2 |------>| UA 2 | . 222 . | | | | . . | | | | . 223 . +-------+ +----+ . . +----+ +-------+ . 224 . Domain A . . Domain B . 225 ............................. .............................. 227 Interfaces: 229 (1) Originating UA 1 to Proxy 1: Authentication and all SIP 230 messages to/from UA 1 231 (1a and 3a) Proxy to AR: instructions to allow voice packet 232 transport 233 (2) Proxy 1 to Proxy 2 (and to other devices such as policy 234 servers): SIP messages and policy actions 235 (3) Proxy 2 to terminating UA 2: Authentication and all SIP 236 messages to/from U 2 237 (4a) Originating UA 1 to AR 1: attempted voice packets 238 (4b) AR 1 to AR 2: authorized voice packets 239 (4c) AR 2 to UA 2: authorized voice packets 241 4. Required Procedures 243 4.1. Authentication 245 Each UA which might use the Assured Service capability must 246 authenticate with a designated proxy before any service activation 247 is attempted. Normally, this would be at the time the device is 248 powered on, connected to the network, or is initialized, or it might 249 authentication requires a user interaction (human entry of a 250 password, retina scan, etc.) is not important and depends on the 251 application. Such an authentication may be very time consuming, with 252 password verification and policy data-base look-ups. After this 253 authentication, this proxy must handle all session establishments, 254 both to and from this UA. 256 This authentication function may be performed when the user attempts 257 the first session setup, for example, when an individual is allowed 258 to use a common device by first "logging on" with their identity and 259 password. In fact, this is still an "authentication" function 260 performed before the session setup is attempted. However, in this 261 case, it must be understood that there may be an additional delay 262 due to the authentication process before a call can be placed. 264 This authentication process is not unique to the provision of the 265 Assured Service capability. It is also required for many other 266 services which are to be provided by the service provider's proxy 267 based on pre-established authorizations. 269 4.2. Function of Proxy 271 Besides the processing of the authentication, each proxy is 272 responsible for a number of functions important to the provision of 273 Assured Service (as well as other services) and the handling of 274 interactions, where required, between different services. This 275 includes (for Assured Service): 277 . maintaining state of all existing sessions, including their 278 priority, which exist on all UAs under its control (both 279 proxies). 281 . maintaining knowledge of other services being used by the UA 282 which might need to be taken into consideration when applying 283 the Assured Service capabilities (both proxies). 285 . verifying that the originating UA is allowed to establish the 286 session at the precedence level requested (originating proxy). 288 . establish permission at the access router for it to handle the 289 precedence marked packets from the UA (both proxies). 291 . performing the timing function to control the diversion service 292 (terminating proxy). 294 . deciding when to preempt the end user and sending the 295 appropriate preempt messages to the other party (both proxies). 297 . maintaining records of the use of the service, whether for 298 accounting or auditing purposes (both proxies). 300 4.3. Function of the Access Router 302 The access router, under control of the proxy, decides which packets 303 are to be transported between networks or domains. If authorization 304 has not been granted for the transport of a specific packet flow at 305 the precedence level indicated in the packets, the access router 306 must discard the packets. 308 Additionally, there may be cases in which a currently transported 309 packet stream must be stopped. Since the Assured Service may not be 310 able to rely on the UA to stop the flow, it may be necessary for the 311 access router, again under control of the proxy, to stop 312 transporting a particular flow. 314 4.4. Session Control 316 Session establishment and release should follow the same message 317 sequence as defined in SIP and its extensions for non-Assured 318 Service calls. There should not be any additional messages for an 319 Assured Service call. The only additional requirements are the 320 inclusion of: 322 . the priority level as defined in [Resource] in the INVITE 324 . security related information in every message which might 325 consist of an authentication header (AH) using cryptographic 326 techniques to allow the receiving end (user or proxy) to 327 validate the authenticity of the message before acting on it. 328 (This requirement is not unique to Assured Service, but is also 329 required to secure other capabilities.) 331 5. Security Considerations 333 This memo mostly deals with the architecture required to support the 334 necessary security. While it does not attempt to define the actual 335 security mechanisms used for authentication and authorization, it 336 establishes the service architecture required as a basis for 337 security. 339 6. References 341 [RFC3261] RFC 3261, "SIP: Session Initiation Protocol", J. 342 Rosenberg, et al, June 2002. 344 [RFC3313] RFC 3313, "Private SIP Extensions for Media 345 Authorization", W. Marshall, May 2002. 347 [RFC3323] RFC 3323 "A Privacy Mechanism for the Session Initiation 348 Protocol (SIP)", J. Peterson, November 2002. 350 [RFC3325] RFC 3325, "SIP extensions for Network-asserted Caller 351 February 2002. 353 [Pierce1] draft-pierce-ieprep-assured-service-req-02, "Requirements 354 for Assured Service Capabilities in Voice over IP", Jan 2004. 356 [Resource] draft-ietf-sip-resource-priority-00, "SIP Communications 357 Resource Priority Header", Henning Schulzrinne and James Polk, June 358 2003. 360 7. Authors' Addresses 362 Michael Pierce 363 Artel 364 1893 Preston White Drive 365 Reston, VA 20191 366 Phone: +1 410.817.4795 367 Email: pierce1m@ncr.disa.mil 369 Don Choi 370 DISA 371 5600 Columbia Pike 372 Falls Church, VA 22041-2717 373 Phone: +1 703.681.2312 374 Email: choid@ncr.disa.mil 376 Full Copyright Statement 378 Copyright (c) The Internet Society (2004). All Rights Reserved. 380 This document and translations of it may be copied and furnished to 381 others, and derivative works that comment on or otherwise explain it 382 or assist in its implementation may be prepared, copied, published 383 and distributed, in whole or in part, without restriction of any 384 kind, provided that the above copyright notice and this paragraph 385 are included on all such copies and derivative works. However, this 386 document itself may not be modified in any way, such as by removing 387 the copyright notice or references to the Internet Society or other 388 Internet organizations, except as needed for the purpose of 389 developing Internet standards in which case the procedures for 390 copyrights defined in the Internet Standards process must be 391 followed, or as required to translate it into languages other than 392 English. 394 The limited permissions granted above are perpetual and will not be 395 revoked by the Internet Society or its successors or assigns. 397 This document and the information contained herein is provided on an 398 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 399 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 400 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 401 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF