idnits 2.17.1 draft-channabasappa-sipua-config-mgmt-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 753. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 760. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 766. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (February 26, 2006) is 6627 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-SIP-CFG' -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-SNMP-SSH' -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-SNMP-TMSM' -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-XCAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'IR-SMI-XML' ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S. Channabasappa 3 Internet-Draft J-F. Mule 4 Expires: August 30, 2006 CableLabs 5 February 26, 2006 7 Use Cases and Considerations for SIP Client Configuration and Management 8 draft-channabasappa-sipua-config-mgmt-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 30, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document provides use cases for the configuration and management 42 of SIP-based devices (SIP client and applications) based on available 43 IETF protocols and related methodologies. The use cases have been 44 made generic enough to take into account common network topologies 45 and requirements in SIP service deployments. 46 Based on the use cases, we present a preliminary analysis of 47 available IETF protocols that meet these requirements and highlight 48 some of the limitations. 50 Finally, a summary section captures the main findings to generate 51 further discussion with the relevant IETF working groups. It is the 52 intent of the authors to seek general feedback from the IETF 53 community on the approaches outlined in this document, especially in 54 the OPS area and in SIPPING. 56 Table of Contents 58 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. SIP UA Config and Management - Basic Scenario and Use Cases . 4 60 3. Use Case 1: SIP client provisioning using XML-based 61 configuration and data modeling . . . . . . . . . . . . . . . 6 62 4. Use Case 2: Access Control Definitions and XML-based 63 configuration methodologies . . . . . . . . . . . . . . . . . 11 64 5. Use Case 3: Management of clients behind firewalls (and 65 NATs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 6. Summary and Next Steps . . . . . . . . . . . . . . . . . . . . 18 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 73 Intellectual Property and Copyright Statements . . . . . . . . . . 24 75 1. Overview 77 A couple of IETF working groups, OPS area and BoF meetings have 78 reported the various emerging models and requirements to configure 79 devices or applications and perform some monitoring or element 80 management of such devices or apps. 81 Various working groups are also defining the new IETF toolkit 82 available to end-users, product vendors, enterprises and service 83 providers to meet these configuration and element management 84 requirements, including NETCONF, ISMS, SIP, SIPPING, SIMPLE, CallHome 85 BoF to cite a few. 86 At the same time, many IP networks are seeing a shift in the types 87 and variety of SIP-based communication clients being used and the 88 associated configuration and management needs are evolving. 89 A communication client may be software or hardware-based, embedded 90 into an access network bridge or router, or a standalone device; it 91 may operate on diverse platforms (PDAs, PCs, Mobile phones, home 92 router) and operating systems (real and non-real time), with 93 differing requirements related to capabilities, memory and CPU 94 constraints. 95 As described in XCAP, multiple end-users can share a client and 96 multiple clients can be bound to an end-user. 98 In short, from a configuration and management standpoint, the above 99 means: 101 o increased configuration requirements to handle multiple profiles 102 and dynamic changes. 103 Configuration changes may be generated by multiple sources: an 104 end-user (based on application usage needs), a client (based on 105 network conditions or profile usage), or an actor (admin user, 106 enterprise IT or service provider sysadmin); 108 o support for configuration and management of clients with single or 109 dual IP stacks with IPv4 and IPv6 support which may be behind NATs 110 and firewalls. 112 This document attempts to describe a basic scenario for configuring 113 and managing SIP devices by providing a couple of common use cases 114 and looking at the available solutions in the IETF toolkit. Our goal 115 is to show the design choices some folks are confronted with and 116 underline open issues to support some of the current IETF work and, 117 more importantly, outline some areas that potentially need more work. 119 2. SIP UA Config and Management - Basic Scenario and Use Cases 121 The basic scenario we use in this document is the one of an end-user, 122 enterprise or service provider (an actor) wanting to configure and 123 manage its SIP-based client and SIP-related application functionality 124 by using available IETF protocols and existing element management 125 tools (through various user interfaces: Command Line Interfaces, web- 126 based views, or even management protocols via SNMP [RFC3411] for some 127 categories of actors). The SIP client may be dual-stack IPv4 and 128 IPv6 and may or may not be behind a home-based or network-based NAT: 129 this special case is only secondary and invoked in the third use 130 case. 132 We consider three use cases derived from this basic scenario: 134 o SIP client provisioning using XML-based configuration protocols 135 with common management and data modeling techniques. 136 The configuration of a SIP client is based on the use of IETF 137 SIPPING Configuration framework ([ID-SIP-CFG]) and the IETF XCAP 138 protocol ([ID-XCAP]) with the addition of commonly used MIB design 139 methodologies using the Structure of Management Information (SMI) 140 to solve the lack of XML data modeling. The use case illustrates 141 the shift in client configuration methodology and elaborates on 142 how SNMP configuration is evolving into XML-based configuration. 143 We insist on some SNMP-based modeling techniques that could be of 144 valuable to re-use for describing data elements for the purpose of 145 management: especially but not exclusively when the SNMP protocol 146 is used for management in conjunction with XML configuration. 148 o Management of access control for SIP client configuration based on 149 SIPPING-config and XCAP based on XML data modeling: 150 When using the IETF SIPPING configuration framework and XML-based 151 configuration via XCAP, the actor should have flexible means to 152 define the type of access on a particular object or XCAP target 153 (read, write, execute, notify, etc.). Access control should also 154 provide multiple access control levels for a particular object, 155 similar to the UNIX access control lists: owner (user), group, 156 others. 158 o Management of SIP devices behind NATs and firewalls: 159 All types of actors want their SIP clients or devices to 160 transparently operate behind well-behaved NATs and firewalls. The 161 use case takes the specific instance of a service provider or an 162 enterprise wanting to manage IPv4-IPv6 SIP devices using CLI or 163 protocols like SNMP or HTTP over secure transport. We look at how 164 management sessions for clients behind firewalls (and may be NATs) 165 require from the use of SIP signaling stimulus. 167 The next sections provide more details on the three distinct use 168 cases and indicate potential solutions based on IETF protocols. 170 3. Use Case 1: SIP client provisioning using XML-based configuration 171 and data modeling 173 In this section, we consider a SIP client being provisioned using 174 XML-based configuration protocols (IETF SIPPING configuration 175 framework and IETF XCAP protocol). We investigate how re-using some 176 of the commonly used MIB design methodologies may help to solve the 177 lack of XML data modeling. 179 While the intent of the use case is generic, taking a specific 180 example of cable service providers should help provide some context. 181 This may also be applicable to other actors, enterprises and service 182 providers in particular. The main point is not to insist on the use 183 of SNMP but more importantly, to underline how engineers and 184 implementers have used the SMI data model associated with SNMP to 185 design configuration files. 186 Traditionally, devices in cable networks (e.g. DOCSIS(r) cable 187 modems, PacketCable VoIP clients) have used SMI-based 188 ([RFC1155],[RFC2578]) SNMP MIB modules as a means to represent both 189 configuration and management data elements. Device management is 190 performed using the IETF SNMP protocols and recommendations. The 191 initial device configuration relies on a configuration file 192 downloaded via TFTP or HTTP whose content includes TLV attributes 193 (Type, Length, Value): each TLV in a typical client configuration 194 file represents an SNMP variable binding: a configuration parameter 195 and its initial value. 197 This process is illustrated in Figure X1. A cable device or client 198 obtains its configuration file, populates the configuration 199 parameters by 'internally' setting the corresponding SNMP MIB objects 200 and proceeds to initialization of the supported services and is ready 201 to be managed by element management systems based on SNMP. 203 Note that the configuration file was provided using TFTP (or HTTP) on 204 a one-time basis (during bootstrapping) as opposed to using a 205 configuration protocol that can support dynamic changes. 207 --------------------------- 208 |Configuration data elements| 209 | Name, data type, default | 210 | value, access type (read, | 211 | write, etc.) | 212 --------------------------- 213 | 214 V 215 ------------------ 216 |MIB module design | 217 | (SMIv2) | 218 ------------------ 219 | 220 V 221 -------------- 222 / \ 223 | Configuration | 224 | file | 225 | (TLV SNMP | 226 | varbinds) | 227 \ / 228 --------------- 229 | 230 V 231 Configuration ---------------- 232 ---------------------------->| TFTP/HTTP | 233 | | Server | 234 | ---------------- 235 V 236 ------------- 237 | Client | 238 ------------- 239 ^ 240 | --------------- 241 | Management | EMS/NMS | 242 ---------------------------->|(SNMP Manager) | 243 --------------- 245 Figure X1: Traditional configuration of cable clients managed via 246 SNMP 248 A couple of points are worth noting in the data modeling process: 249 - Modeling data using SMI to create a MIB module may not always be 250 perceived as adequate, elegant or efficient by many, but there are 251 many design guideline documents available and it is used by the MIB 252 designers in the IETF community. The experience gained over the 253 years is invaluable; 254 - there are many tools available to check the syntax of MIB modules 255 and enforce strict adherence to the SMI (e.g. boundaries for integer 256 values, default values, formatting of the display of strings, re- 257 usability of textual conventions facilitating interoperability and 258 eliminating the parsing of free form strings, etc.); 259 - there are numerous data models built on SMI that would benefit from 260 being available in the XML-based data modeling world in support of 261 configuration or management. 263 Moving to the use case at hand, the increased client configuration 264 requirements, the recognition that SNMP is rarely used for 265 configuration (NETCONF), and the good work done by the IETF SIPPING 266 working group on the configuration framework (([ID-SIP-CFG])) has led 267 many to explore an XML-based configuration model. 269 The configuration of SIP-based clients and devices in this example is 270 based the configuration proposals available in the IETF for SIP User 271 Agents (UAs) configuration, the eXtensible Markup Language 272 Configuration Access Protocol (XCAP) is chosen as the configuration 273 protocol of choice for this use case. 274 Client management is left unexplored by many proposals: it is not in 275 scope of XCAP or not fully addressed by NETCONF. In this use case, 276 we propose to use SMI for three main reasons: 277 1. to overcome the lack of XML data modeling for element management 278 and configuration, 279 2. to leverage the guidelines and experience in doing configuration 280 and management modeling using well-defined techniques, 281 3. to provide continuity for some actors that may manage devices 282 using SNMP. 283 This may be where the use case becomes more specific but we believe 284 that even without the use of SNMP, re-using SMI brings some clear 285 advantages. 287 For these reasons, SMI-to-XML Schema transformations are accomplished 288 to provide XML Schemas ([IR-SMI-XML]). This enables the same 289 operation as shown in Figure X1, but supports a full-fledged SIPPING 290 and XCAP configuration protocols and allows SNMP management (SNMP 291 management means SNMP for monitoring here (e.g. GET), not for 292 configuration (e.g. SET)). 294 Given the IETF does not have any standard XML-based data modeling 295 proposals, the SMI-to-XML conversion mechanism seems to provide a 296 stop-gap solution for supporting some element configuration. It is 297 important to realize that folks who do not want to deal with SMI or 298 ASN.1 will obtain the derived XML schemas. Rather than defining 299 those schemas from scratch, SMI is used as an intermediary step. 300 This may be seen as short-sighted but in the short term, and 301 potentially long-term, it may provide a viable solution. 303 ------------------ 304 |MIB module design | 305 | (SMI) | 306 ------------------ 307 | 308 V 309 -------------- 310 / \ 311 | SMI to XML | 312 \ / 313 --------------- 314 | 315 V 316 Configuration ---------------- 317 ---------------------------->| XCAP | 318 | | Server | 319 | ---------------- 320 V 321 ------------- 322 | Client | 323 | SIP UA | 324 ------------- 326 Figure X2: Configuration of SIP clients via XCAP using SMI for data 327 modeling 328 ------------------ 329 |MIB module design | 330 | (SMI) | 331 ------------------ 332 | 333 V 334 -------------- 335 / \ 336 | SMI to XML | 337 \ / 338 --------------- 339 | 340 V 341 Configuration ---------------- 342 ---------------------------->| XCAP | 343 | | Server | 344 | ---------------- 345 V 346 ------------- 347 | Client | 348 | SIP UA | 349 |+ SNMP Client| 350 ------------- 351 ^ 352 | --------------- 353 | Management | EMS/NMS | 354 ---------------------------->|(SNMP Manager) | 355 --------------- 357 Figure X3: Configuration of SIP clients via XCAP and Management via 358 SNMP 360 In conclusion, the co-authors believe that a well-defined XML data 361 model for configuration and management is required. While it has 362 surfaced in some working groups (netconf [ID-NETCONF] for example), 363 it is not available today. The long-term solution may be to define a 364 new model in IETF or elsewhere but in the short-term, given the 365 availability of SMI design guidelines and tools, and the experience 366 that can be leveraged from the SNMP community on configuration data 367 design, the IETF should continue the work initiated on SMI-to-XML to 368 provide a standard means to perform quick and reliable syntax 369 conversions. 371 4. Use Case 2: Access Control Definitions and XML-based configuration 372 methodologies 374 Access control definitions allow data model designers to choose 375 access rights and restrictions for the defined data elements. Most 376 everyone is familiar with the UNIX ACL management associated with the 377 file system: each file has read/write/execute access rights for the 378 owner, group, and others. The View-based Access Control Model (VACM) 379 for SNMP is also a good reference as it is applied to configuration 380 ([RFC3415]). 382 In this use case, we look at the change in data ownership that is 383 introduced by XML-based configuration models and protocols (XCAP as 384 an example) and conclude that access control definitions for XML- 385 based data models is a necessity. This use may be viewed as an 386 extension of the first one and it also shows some areas that are not 387 addressed by the SMI-to-XML conversions. 389 Use case description: 390 A SIP client is configured using the SIPPING configuration framework 391 and XCAP. Changes in the configuration data elements may occur at 392 multiple levels (write access): based on end-user settings on the SIP 393 device, remote configuration changes (end-user accessing a web-based 394 interface to change settings or a service operator updating the 395 config), and many other means (software updates from device 396 manufacturer changing some default configuration parameters, etc.). 397 Furthermore, the presentation of some configuration data (read 398 access) may also have to be controlled: not all users of a client may 399 be allowed to change the settings, some settings may be hidden by the 400 protocol stacks, device manufacturers or service providers so that 401 end-users may not misconfigure the device and disrupt the service. 402 Note that the mechanism by which the configuration change is not a 403 factor in this use case: a configuration change may be operated via a 404 custom user interface on the SIP device or application, an end-user 405 or operator controlled CLI, remote web-based interface. 407 Problem statement: 408 How does the designer of the XML schema specify access rights for 409 each data element and for each level (owner, group, others) in an 410 interoperable manner? 412 To provide more context to the use case, we compare this problem 413 statement with the SNMP or SMI-based model even though, as stated 414 above, the problem statement is independent of SNMP. Clients with an 415 SNMP agent store configuration data as instances of the SNMP MIB 416 objects. Changes to such data by authorized network elements is 417 accomplished via SNMP through EMS and NMS systems. Any change is 418 authorized by the SNMP agent based on the SMI access control 419 definitions (specified by the MAX-ACCESS clause). 420 This arrangement is suitable when dynamic configuration changes are 421 minimal: the configuration data is stored on the client and the model 422 works well when there is a single source of changes. There are 423 examples of MIB modules that have been defined where an object was 424 not writable via SNMP but since the object value could be changed 425 during runtime or by the end-user: a note was put in the DESCRIPTION 426 clause. 427 This is illustrated in Figure Z1. 429 ---------- 430 | Network | 431 | Elements | 432 ---------- 433 | 434 | 435 | Configuration 436 | Changes 437 ---------------- | 438 | Client | | 439 | (SNMP agent) | V 440 | ------------ | --------- 441 | | Config | | Configuration changes | EMS/NMS | 442 | | Data | |<------------------------->| (SNMP | 443 | ------------ | | Manager)| 444 | ----------- | --------- 445 | | Management | | Management | 446 | | Data | |<------------------------------- 447 | ----------- | 448 | | 449 ---------------- 451 Figure Z1: Example of Configuration and Management using SNMP 453 With the use of a configuration protocol like XCAP, this paradigm has 454 shifted as illustrated in Figure Z2. 456 ---------- 457 | Network | 458 | Elements | 459 ---------- 460 ^ 461 | 462 -------------- | 463 | Config Server | | 464 | (XCAP Server) | | 465 | ----------- | | 466 | | Config | | | 467 | | Data | |<--------- 468 | ----------- | 469 --------------- 470 ^ 471 Configuration | 472 ----------------------- 473 | 474 | 475 | 476 V 477 ---------------- 478 | Client | 479 | (XCAP Client) | -------------------- 480 | ----------- | Management | Management App | 481 | | Management | |<----------------------| (SNMP, CLI, | 482 | | Data | | | web-based etc) | 483 | ----------- | -------------------- 484 ---------------- 486 Figure Z2: Configuration and Management using various protocols 488 A separate configuration server (for example, the XCAP Server in the 489 above figure) is responsible for the storage and modification of 490 data. This configuration data is accessible by clients and 491 authorized network elements alike. 493 The importance of access control can be illustrated by many examples: 494 assume a data element that is accessible by both the client and a 495 network element, but is modifiable only via the network element 496 (e.g.: my speed dial list or favorite friends' URI list is modifiable 497 via a web-based application talking to the "Network Element"). One 498 would expect the XCAP server, the 'keeper' of the data, to enforce 499 this access control requirement. Should this be expressed in the XML 500 Schema? 501 Further, multiple data profiles can be built out of the same set of 502 data elements, but with different access control settings. There may 503 also be multiple entity types that share the same access control 504 sets. All this hints at UNIX-like or VACM-like grouping of access 505 controls. 507 Additionally, the fact that the same XML Schema definitions may call 508 for run-time change in access privileges should also be taken into 509 consideration. This may call for the ability to provide access 510 control definitions internal or external to the XML data models (for 511 example via XPATH). 513 In conclusion, as we hope this use case illustrates, the co-authors 514 believe there is a need for standardization of Access Control 515 directives to enable configuration and management in general, and 516 XCAP in particular, to be effectively deployed at wide scale and for 517 a wide range of applications. 519 5. Use Case 3: Management of clients behind firewalls (and NATs) 521 The issues of establishing SIP sessions behind NATs and firewalls 522 have been extensively discussed in IETF in SIPPING, BEHAVE, MIDCOM 523 and other groups. We focus on the establishment of a management 524 session between a SIP client and a management stationt 'separated by 525 a firewall (and NAT) device. Any command or management operation 526 should be initiated by the client. 528 ------------ ------- --------------- 529 | Client | |NAT-FW | | EMS/NMS/web | 530 | | |Device | | Mgmt Station | 531 ------------- ------- --------------- 532 | | | 533 | X|<-----------------| Retrieve Operations 534 | | | (Management host 535 | | | initiated) 536 | | | 537 | | | 538 | | | 539 | X|<-----------------| Modification Operations 540 | | | (Management host 541 | | | initiated) 542 | | | 543 | | | 544 | | | 545 | | | Notifications 546 |--------------->|----------------->| (Client initiated) 547 | | | 548 | | | 550 Figure Y2: Management operations affected in the presence of 551 firewalls (and sometimes NATs depending on the protocol used) 553 A management session may be established by the client for an 554 undefined period of time (session stays up which could be resource 555 intensive). For efficiency, it should be initiated as needed, based 556 on a stimulus from the management host. For SIP clients, this 557 solution may be made possible by using the same signaling mechanisms 558 proposed in the SIPPING Configuration framework, for e.g. using the 559 SIP SUBSCRIBE/NOTIFY framework. A client could subscribe to 560 management events and would get notified to initiated a management 561 session. This is illustrated in Figure Y3. 563 ------------ ------- --------------- 564 | Client | | NAT | | EMS/NMS | 565 | | | fw | | | 566 ------------- ------- --------------- 567 | | | 568 |< - - - - - - - |----------------->| Previously 569 | | | established SIP 570 | | | session 571 | | |(e.g. SIP SUBSCRIBE/NOTIFY) 572 | | | 573 |<- - - - - - - -|<-----------------| Notification 574 | | | (e.g. SIP NOTIFY) 575 | | | 576 | | | 577 |- - - - - - - - |----------------->| Management Session 578 | | | establishment 579 | | | (CLI or SNMP over ssh, 580 | | | HTTPS, etc.) 581 | | | 582 |<- - - - - - - >|<---------------->| Retrieve Operations 583 | | | (Management initiated) 584 | | | 585 | | | 586 | | | 587 |<- - - - - - - >|<---------------->| Modification Operations 588 | | | (Management initiated) 589 | | | 590 | | | 591 | | | 592 | | | Notifications 593 |- - - - - - - ->|----------------->| (Client initiated) 594 | | | 595 | | | 597 Figure Y3 Initiating management sessions in the presence of firewall 598 - NAT devices 600 In conclusion, the use case highlights the needs to define a generic 601 mechanism for establishing a client-initiated management connection 602 when a SIP session pre-exists. 603 The components of such a solution may include: 604 - defining how SIP can be used to establish a management session, 605 - defining a SIP event package for conveying the relevant management 606 session parameters (IP and transport addresses of the management 607 station, the type of transport protocol to use for management - 608 HTTPS, SNMP over SSH, etc.). 610 6. Summary and Next Steps 612 In summary, this document presents three use cases for the 613 configuration and management of SIP clients or devices using IETF 614 protocols. The proposed approaches lead to following findings and 615 suggestions: 617 o An XML data modeling specification for configuration and 618 management is required. The experimental SMI to XML conversion 619 methods provide an elegant, short term solution for some actors. 620 It leverages the experience and tools for building modules for 621 management purposes. It allow the reuse of some existing data 622 models based on SMI with XML based configuration protocols like 623 XCAP ([ID-XCAP]). There have been proposals in the past 624 ([IR-SMI-XML]) that have been implemented, and, based on some 625 prototyping experimentation, the co-authors of this document 626 recommend that this proposal be revisited. 628 o XML-based configuration protocols can greatly benefit from a 629 standardized access control definition methodology. This would 630 foster effective deployment of XML based configuration protocols. 632 o Solutions developed in some OPS working groups should address the 633 management of clients behind NATs and firewalls, so that IPv4 and 634 dual-stack IPv4-IPv6 clients may be managed efficiently. An 635 example specific to SNMP would be to invite proposals to the ISMS 636 WG to help address the NAT and firewall traversal within the scope 637 of modified transport ([ID-SNMP-SSH]) and security models 638 ([ID-SNMP-TMSM]). 640 o The SIP community may benefit from defining solutions to enable 641 client-initiated management connection when a SIP session exists. 642 A new SIP event package may be used part of the solution 643 ([RFC3265]). 645 7. Acknowledgments 647 The authors of this draft wish to thank members of the CableLabs 648 PacketCable focus teams and various other IETF participants who 649 contributed directly or indirectly to the content presented in this 650 draft. Specifically, the following individuals are recognized: Josh 651 Littlefield, Eugene Nechamkin, Paul Duffy, Thomas Clack, Harindranath 652 P.R Nair. 653 We also thank Juergen Schoenwaelder and Frank Strausse for the email 654 exchanges. 656 8. Security Considerations 658 FFS. 660 9. References 662 9.1. Normative References 664 [ID-SIP-CFG] 665 Petrie, D., "A Framework for Session Initiation Protocol 666 User Agent Profile Delivery", July 2005. 668 [ID-SNMP-SSH] 669 Harrington, D. and J. Salowey, "Secure Shell Security 670 Model for SNMP", Feb 2006. 672 [ID-SNMP-TMSM] 673 Harrington, D. and J. Schoenwaelder, "Transport Mapping 674 Security Model (TMSM) for the Simple Network Management 675 Protocol", Oct 2005. 677 [ID-XCAP] Rosenberg, J., "The Extensible Markup Language (XML) 678 Configuration Access Protocol (XCAP)", October 2005. 680 [IR-SMI-XML] 681 Schoenwaelder, J., "Using XML to Exchange SMI 682 Definitions", January 2002. 684 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification 685 of management information for TCP/IP-based internets", 686 STD 16, RFC 1155, May 1990. 688 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 689 Schoenwaelder, Ed., "Structure of Management Information 690 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 692 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 693 Event Notification", RFC 3265, June 2002. 695 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 696 Architecture for Describing Simple Network Management 697 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 698 December 2002. 700 9.2. Informative References 702 [ID-NETCONF] 703 Enns, R., "NETCONF Configuration Protocol", Feb 2006. 705 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 706 Access Control Model (VACM) for the Simple Network 707 Management Protocol (SNMP)", STD 62, RFC 3415, 708 December 2002. 710 Authors' Addresses 712 Sumanth Channabasappa 713 CableLabs 714 858 Coal Creek Circle 715 Louisville, CO 80027 716 USA 718 Email: sumanth@cablelabs.com 720 Jean-Francois Mule 721 CableLabs 722 858 Coal Creek Circle 723 Louisville, CO 80027 724 USA 726 Email: jfm@cablelabs.com 728 Full Copyright Statement 730 Copyright (C) The Internet Society (2006). 732 This document is subject to the rights, licenses and restrictions 733 contained in BCP 78, and except as set forth therein, the authors 734 retain all their rights. 736 This document and the information contained herein are provided on an 737 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 738 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 739 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 740 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 741 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 742 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 744 Intellectual Property 746 The IETF takes no position regarding the validity or scope of any 747 Intellectual Property Rights or other rights that might be claimed to 748 pertain to the implementation or use of the technology described in 749 this document or the extent to which any license under such rights 750 might or might not be available; nor does it represent that it has 751 made any independent effort to identify any such rights. Information 752 on the procedures with respect to rights in RFC documents can be 753 found in BCP 78 and BCP 79. 755 Copies of IPR disclosures made to the IETF Secretariat and any 756 assurances of licenses to be made available, or the result of an 757 attempt made to obtain a general license or permission for the use of 758 such proprietary rights by implementers or users of this 759 specification can be obtained from the IETF on-line IPR repository at 760 http://www.ietf.org/ipr. 762 The IETF invites any interested party to bring to its attention any 763 copyrights, patents or patent applications, or other proprietary 764 rights that may cover technology that may be required to implement 765 this standard. Please address the information to the IETF at 766 ietf-ipr@ietf.org. 768 Acknowledgment 770 Funding for the RFC Editor function is currently provided by the 771 Internet Society.