idnits 2.17.00 (12 Aug 2021) /tmp/idnits14594/draft-boucadair-netconf-req-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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 888. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 865. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 872. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 878. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 18) being 77 lines 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: As far as scalability is concerned, adequate indicators SHOULD be specified in order to qualify the ability of a given technical means to support a large number of configuration processes. The maintenance of these processes SHOULD not impact the performance of a given system (a system is a set of elements that compose the key fundamentals of an architecture that aims at delivering configuration data). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 1. The activation of the protocol by the participating devices SHOULD not affect the overall switching performances of such devices, whatever the volume of configuration data these devices will have to process on a given period of time, -- 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 6512 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 779, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. '9') (Obsoleted by RFC 4301) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 netconf Working Group M. Boucadair 2 INTERNET-DRAFT C. Jacquenet 3 Document: draft-boucadair-netconf-req-00.txt M. Achemlal 4 Category: Informational Y. Adam 5 Expires January 2005 France Telecom 6 July 2004 8 Requirements for Efficient and Automated Configuration Management 9 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 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 Abstract 35 Given the ever-increasing importance of configuration tasks for the 36 provisioning of a wide range of IP resources, networks, and services 37 in today's Internet, this draft aims at listing the basic 38 requirements that should drive the specification of a protocol to 39 convey configuration information towards network devices. This memo 40 doesn't aim at listing candidate protocols to convey such 41 information, nor at choosing one of these. This draft basically 42 describes a whole set of issues a service provider has to deal with, 43 hence a list of requirements to better address such issues. 45 Table of Contents 47 1. Introduction................................................3 48 2. Conventions used in this document...........................3 49 3. Terminology.................................................3 50 4. Motivations and Goals.......................................5 51 5. Positioning this Draft within the NETCONF Working Group.....5 52 6. Current Issues with Configuration Procedures................6 53 6.1. Protocol Diversity..........................................6 54 6.2. Topology Discovery..........................................6 55 6.3. Device capabilities discovery...............................6 56 6.4. Impact on the performance...................................7 57 6.5. Scalability.................................................7 58 6.6. Automation..................................................7 59 6.7. Security issues.............................................8 60 7. Towards a Service-Oriented Configuration Policy.............8 61 8. Requirements................................................9 62 8.1. Protocol Requirements.......................................9 63 8.1.1. Functional Requirements.....................................9 64 8.1.2. Performance requirements...................................10 65 8.1.3. Backward Compatibility.....................................10 66 8.2. Information requirements...................................10 67 8.2.1. Network services...........................................11 68 8.2.1.1. Identification of Interfaces.............................11 69 8.2.1.2. Quality of Service (QoS).................................12 70 8.2.1.3. Security.................................................12 71 8.2.1.4. Applications.............................................12 72 8.2.2. Forwarding services........................................13 73 8.2.2.1. Routing and Forwarding Configuration Information.........13 74 8.2.2.2. Traffic Engineering Configuration Information............13 75 8.2.2.3. Configuration Information for Tunnel Design and 76 Activation...............................................13 77 8.2.2.4. Tunnel Identification Information........................14 78 8.2.2.5. Tunneling Protocol Configuration Information.............14 79 8.2.3. Management services........................................14 80 8.2.3.1. Fault Management.........................................14 81 8.2.3.2. Configuration Management.................................14 82 8.2.3.3. Performance Management...................................15 83 8.2.3.4. Security Management......................................15 84 8.2.3.4.1. Device Authentication..................................15 85 8.2.3.4.2. Integrity of configuration information.................15 86 8.2.3.4.3. Confidentiality of exchanged data......................15 87 8.2.3.4.4. Key management.........................................16 88 8.2.3.4.5. Log of connections.....................................16 89 8.2.3.4.6. Profiles...............................................16 90 9. Security Considerations....................................16 91 10. References.................................................16 92 11. Acknowledgments............................................17 93 12. Authors' Addresses.........................................17 95 1. Introduction 97 In today's Internet, configuration procedures are achieved by 98 technical personnel who's required an ever-growing level of expertise 99 because of the various technologies and features that need to be 100 used, configured and activated to deploy a wide range of IP service 101 offerings. This level of expertise has become mandatory as each 102 equipment manufacturer has developed its own interfaces and 103 configuration schemes. In addition, as IP services may rely upon the 104 activation of a set of sophisticated yet complex features, the time 105 to adequately provision such services is also increasing. 107 As a consequence, the specification and the use of standardized 108 protocol (for conveying configuration information) and interfaces 109 SHOULD dramatically help in facilitating if not automating the 110 configuration process and the operational production of a wide range 111 of IP services. 113 This draft aims at describing basic requirements for configuration 114 task purposes, from a service provider perspective. 116 This document is structured as follows: 118 - Section 3 introduces some terminology that is used by this 119 document 120 - Section 4 presents the goals and motivations of this draft 121 - Sections 5 position this draft within the current netconf 122 working group initiative. 123 - Section 6 summarizes important issues that are related to 124 configuration tasks in today's IP networks. 125 - Section 7 discusses the importance of introducing a service- 126 oriented configuration scheme. 127 - Section 8 lists configuration information and protocol 128 requirements. 130 2. Conventions used in this document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [2]. 136 3. Terminology 138 This section aims at providing a set of basic definitions for the 139 terms that will be used by this document. 141 . Decision point: is an entity that is responsible for generating 142 decisions related to configuration tasks that yield the 143 production of configuration data which needs to be conveyed 144 towards (and processed by) a participating device. 146 . Endpoint: one of the extremities of a tunnel. 148 . Participating device: any networking equipment that will 149 participate in the establishment, the activation and the 150 maintenance of a given network service. Such devices may 151 include routers and hosts, whatever the configuration 152 procedures and underlying technologies to be used for the 153 deployment of such service. 155 . Subscriber: A subscriber (or a customer) is a legal 156 representative who has the (legal) ability to subscribe to a 157 service offering. 159 . Tunnel activation: the configuration tasks that position a 160 tunnel facility into an activated state, so that it can be used 161 to convey traffic. Obviously, a tunnel must not (and, 162 hopefully, cannot) be activated before it has been established. 164 . Tunnel establishment: all the configuration tasks that lead to 165 the configuration of a tunnel facility. Once the tunnel is 166 established, it needs to be activated in order to be able to 167 convey traffic. 169 . Tunnel maintenance: the period of time during which a tunnel 170 facility remains activated. 172 . Tunnel: a tunnel is a transport facility that is designed to 173 convey' (IP) data traffic between one endpoint and another 174 (point-to-point tunnels), or between one endpoint and several 175 others (point-to-multipoint tunnels). Tunnels can be used for 176 different purposes, e.g.: 178 - Access IP multicast networks over IP clouds that do not 179 support multicast forwarding capabilities, 180 - Access IPv6 networks over IPv4 clouds, 181 - Deploy IP Virtual Private Networks, 182 - Deploy Mobile IP architectures. 184 . User: A user is an entity (a human being or a process, from a 185 general perspective) who has been identified (and possibly 186 authenticated) by a service provider, and who will access this 187 service offering according to his associated rights and duties. 189 . VPN: Virtual Private Network. A collection of switching 190 resources (e.g. routers) and transmission resources that will 191 be used over an IP backbone thanks to the establishment and the 192 activation of tunnels. These tunnels will convey the IP traffic 193 that characterizes the data oriented-communication service of a 194 customer (VPNs that are designed to support intranet-based 195 applications) or a set of customers (VPNs that are designed to 196 support extranet-based applications). Thus, IP VPN networks are 197 an applicability example of tunnel configuration and management 198 activities. 200 4. Motivations and Goals 202 Operators and protocol developers have gained experience to 203 implement, deploy and manipulate a large set of protocols and 204 associated information. Some data models have also been defined for 205 network management purposes. Thus, several protocols have been 206 standardized, such as SNMP (Simple Network Management Protocol, RFC 207 3410([3])), COPS (Common Open Policy Service, RFC 2748([4])), (COPS- 208 PR, RFC 3084([5])). Multiple data models have been defined and used 209 by operators like: CIM (Core information model, [6]), DEN (Directory 210 enabled Network), SMI (Structure of Management Information, [7]), 211 SPPI (Structure of Policy Provisioning Information, [8]), MIB 212 (Management Information Base), PIB (Policy Information Management)à 214 Despite this standardization effort, some operators and 215 standardization bodies address a negative report (RFC3535) about the 216 capacity of existing tools to deal with operator's requirements about 217 network management and configuration operations. 219 The purpose of this document is to clarify what are such requirements 220 from a configuration task perspective. This initiative also aims at 221 gathering any feedback from other service providers or vendors in 222 order to agree on a common yet consolidated set of requirements, 223 which SHOULD dramatically help in facilitating if not automating the 224 configuration process and the operational production of a wide range 225 of IP services. 227 5. Positioning this Draft within the NETCONF Working Group 229 In mid-2003, the IETF netconf (Network Configuration) working group 230 has been set up. The main objective of netconf is to produce a 231 protocol suitable for network configuration. A proposal to use XML 232 (Extensible Markup Language) for configuration purposes has been 233 adopted. The choice of this technology hasn't been motivated nor 234 discussed by some formal document yet. 236 For instance, neither an analysis of existing configuration-based 237 protocols nor a requirement draft have been published. Therefore, 238 there is no explicit consensus about this technical choice (possibly 239 an implicit consensus between some netconf WG members). Because of 240 the lack of guidance documents (framework and requirement documents) 241 and also of a clear view on the actual requirements, the netconf 242 working group may experience some difficulties to make the Internet 243 community widely adopt its ongoing protocol specification effort. 245 6. Current Issues with Configuration Procedures 247 This section aims at listing issues that SHOULD be carefully studied 248 when dealing with configuration tasks. The items below SHOULD be 249 taken into account when designing a protocol for configuration 250 purposes. 252 6.1. Protocol Diversity 254 The production of a whole set of IP yet complex services relies upon 255 the activation of a set of capabilities in the participating devices. 256 Especially, a large set of protocols need to be configured, such as 257 routing protocols, management protocols, security protocols, not to 258 mention capabilities that relate to addressing scheme management, QoS 259 policy enforcement, etc. 261 Such a diversity of features and protocols MAY increase the risk of 262 inconsistencies. Therefore, the configuration information which is 263 forwarded to the whole set of participating devices for producing a 264 given service or a set of services SHOULD be consistent, whatever the 265 number of features/services to be activated/deployed in the network. 267 6.2. Topology Discovery 269 Network operators SHOULD have means to dynamically discover the 270 topology of their network. This topology information should be as 271 elaborate as possible, including details like: the links that connect 272 network devices, including information about their capacity, such as 273 the total bandwidth, the available bandwidth, the bandwidth that can 274 be reserved, etc. 276 6.3. Device capabilities discovery 278 As stated above a large number of participating devices are involved 279 in deploying and offering IP-based services. These devices could vary 280 depending on the following: 282 - The manufacturer in charge of designing these devices 283 - The version of operating system of the devices 284 - The supported protocols 285 - Configuration tools 286 - Others 288 As a result, it isn't evident to have homogenous capabilities and 289 means to activate similar functionalities in two participating 290 devices. Therefore, operators SHOULD have means to (1) detect the 291 capabilities, (2) have an exhaustive description and (3) list 292 activated process and functions of a given of participating devices. 294 This COULD be done automatically or in demand. 296 6.4. Impact on the performance 298 Configuring network devices and IP services is a human task, and 299 occurrences of erroneous configurations are therefore plausible. Such 300 occurrences MAY seriously affect the overall quality of a service, 301 like the access to a service or its global availability. From this 302 perspective, some performance indicators SHOULD be defined and 303 measured to qualify: 305 - The impact of any modification of an operational configuration, 306 in terms of performances, 308 - The time needed to deliver and achieve any elementary 309 configuration task. 311 Simulation tools can also be useful to qualify any possible impact of 312 an elementary configuration task before such task is performed. 314 6.5. Scalability 316 As far as scalability is concerned, adequate indicators SHOULD be 317 specified in order to qualify the ability of a given technical means 318 to support a large number of configuration processes. The maintenance 319 of these processes SHOULD not impact the performance of a given 320 system (a system is a set of elements that compose the key 321 fundamentals of an architecture that aims at delivering configuration 322 data). 324 Therefore, configuration operations SHOULD be qualified with 325 performance indicators in order to check whether the architecture 326 designed for configuration management is scalable in terms of: 328 - Volume of configuration data to be processed per unit of time 329 and according to the number of capabilities and devices that 330 need to be configured, 331 - Volume of information generated by any reporting mechanism that 332 may be associated to a configuration process, 333 - Number of processes that are created in order to achieve 334 specific configuration operations, 336 6.6. Automation 338 The efficiency of a configuration process SHOULD be enhanced by the 339 introduction of the highest level of automation when performing 340 configuration tasks. 342 Automation is defined as follows: 344 - Automatic provisioning of configuration information to the 345 participating devices, 346 - Dynamic enforcement of configuration policies, 347 - Dynamic reporting mechanisms to notify about the actual 348 processing of configuration information by a participating 349 device. 351 6.7. Security issues 353 Configuring a network or a service raises several security issues 354 that need to be addressed, such as: 356 - The integrity of the configuration information, possibly 357 yielding the preservation of the confidentiality of such 358 information when being conveyed over a public IP 359 infrastructure, 361 - The need for authorizing and authenticating devices/entities 362 that have the ability of manipulating configuration information 363 (define, instantiate, forward and process). 365 - Mutual authentication between a decision point and a device 366 that will receive configuration data 368 In addition, additional configuration data SHOULD NOT yield 369 additional security lacks. 371 7. Towards a Service-Oriented Configuration Policy 373 Current configuration practice basically focuses on elementary 374 functions, i.e. configuration management for a given service offering 375 is decomposed in a set of elementary tasks. Thus, the consistency of 376 configuration operations for producing IP services MUST be checked by 377 any means appropriate, while current. Configuration methods can, at 378 best, only check if provisioning decisions are correctly enforced by 379 a single device. 381 A network device SHOULD be seen as a means to deploy a service and 382 not just as a component of such service. Thus, service configuration 383 and production techniques SHOULD NOT focus on a set of devices taken 384 one-by-one, but on the service itself, which will rely upon a set of 385 features that need to be configured and activated in various regions 386 of the network that supports such service. 388 Service providers could dedicate centralized entities that will be 389 responsible for the provisioning and the management of participating 390 devices. The main function of these centralized entities is to make 391 appropriate decisions and generate convenient configuration data that 392 will be delivered to the participating devices. In addition, these 393 centralized entities will make sure of the consistency of the 394 decisions that have been taken to produce the service, as per a 395 dynamic configuration policy enforcement scheme. 397 Service-oriented configuration SHOULD rely upon the following 398 requirements: 400 - The data models MUST be service-oriented; 401 - The configuration protocol(s) SHOULD at large extent possible 402 reuse existing data and information models; 403 - The configuration protocol(s) SHOULD be open for further 404 enhancement and adding new functionalities that could reveal in 405 the future as a must; 406 - The configuration protocol(s) SHOULD provide means to validate 407 the consistence and the validation of service configuration 409 8. Requirements 411 8.1. Protocol Requirements 413 Configuration information SHOULD be provided to the participating 414 devices by means of a communication protocol that would be used 415 between the aforementioned participating devices and a presumably 416 centralized entity that would aim at storing, maintaining and 417 updating this configuration information as appropriate, as well as 418 making adequate decisions at the right time and under various 419 conditions. 421 8.1.1. Functional Requirements 423 The vendor-independent communication protocol for conveying 424 configuration information SHOULD have the following characteristics: 426 1. The protocol SHOULD use a reliable transport mode, and independent 427 from the network layer (i.e. IPv4/IPv6), 429 2. The protocol architecture SHOULD provide a means for dynamically 430 provision the configuration information to the participating 431 devices, so that it may introduce a high level of automation in 432 the actual negotiation and invocation of a a whole range of IP 433 service offerings. 435 3. The protocol SHOULD provide the relevant means (encoding 436 capabilities, operations and command primitives, extension 437 capabilities that SHOULD allow additional operations, etc.) to be 438 able to reliably convey any kind of configuration information, 440 4. The protocol SHOULD be a privileged vector for the dynamic 441 provisioning of any kind of configuration data, as well as the 442 dynamic enforcement of any kind of policy such as a routing 443 policy, a QoS policy and/or a security policy. This requirement 444 MAY yield the definition and the support of vendor-independent 445 instantiation procedures that will aim at uniquely identifying the 446 configuration data model and/or the policy enforcement scheme that 447 refer to a given IP service offering. 449 5. The protocol SHOULD support a reporting mechanism that may be used 450 for statistical information retrieval, 452 6. The protocol SHOULD support the appropriate security mechanisms to 453 provide guarantees as far as the preservation of the 454 confidentiality of the configuration information is concerned. 456 7. The protocol SHOULD support a notification mechanism that may be 457 used to initiate configuration-related tasks (i.e. inform that a 458 link drop down) 460 8.1.2. Performance requirements 462 The protocol architecture for conveying configuration information 463 within a network SHOULD be designed so that: 465 1. The activation of the protocol by the participating devices SHOULD 466 not affect the overall switching performances of such devices, 467 whatever the volume of configuration data these devices will have 468 to process on a given period of time, 470 2. The activation of the protocol SHOULD NOT dramatically affect the 471 global resources of the network infrastructure that will convey 472 the protocol-specific traffic, whatever the volume of such traffic 473 and whatever the scope (set of IP service offerings the 474 configuration data refer to, set of policies to dynamically 475 enforced, etc.) covered by such traffic. 477 8.1.3. Backward Compatibility 479 The introduction and the activation of a protocol for conveying 480 configuration data SHOULD allow for smooth migration procedures, so 481 that vendor-specific and vendor-independent configuration procedures 482 and management MAY gracefully co-exist on a (hopefully) limited 483 period of time. 485 Also, in case of any kind of protocol failure, it MUST be possible to 486 rely upon any vendor-specific configuration procedure to keep on 487 performing configuration tasks without any risk of disruption that 488 may affect the availability of a (set of) service offerings, and/or 489 the access to network resources. 491 8.2. Information requirements 492 The increase of network service offerings, of the protocol amount to 493 be implemented by equipment as well as the diversity of vendors made 494 the configuration tasks being critical. These tasks are commonly 495 achieved with vendor-specific solutions that deal with device-related 496 information. Moreover the configuration information may be spread 497 across different repositories through the network. It then becomes 498 more and more difficult for the service provider to get a unified 499 (and obviously confident) view of its network in term on æoffered 500 servicesÆ rather than a ænetwork device jigsawÆ. 502 Configuration information SHOULD therefore be provided to the 503 participating devices as unified service parameters being independent 504 from the aforementioned devices vendors. These parameters MUST relate 505 to a standardized service model rather than device-specific as it 506 used to be. Examples of the so-called service model may be tunneling 507 service, internal routing service, VPN service. Their definition is 508 outside the scope of this draft. 510 Current service providers' concerns focus on the unification of 511 accesses to heterogeneous devices (those that are part of a multi- 512 vendor environment) and introduce a high level of automation when 513 achieving configuration of this infrastructure. This unification 514 depends on two major issues, the definition of a protocol (the 515 container) and the definition of data models (the content). 516 Standardizing these two points bring new opportunities: 518 - Equipment are seen as functional blocks providing a set of 519 standardized capabilities; 521 - These functional blocks are described as vendor-independent 522 capabilities; 524 - These functional blocks are all managed homogeneously, whatever 525 the underlying technology; 527 As a result, it would be possible to add semantic rules to automate 528 detection and correction of false configurations, either at the scale 529 of a single device or at the scale of a whole network. Furthermore, 530 an equipment from vendor X could de replaced by another device from 531 vendor Y with no impact on the configuration management. 533 To do so, the data models SHOULD satisfy the requirements described 534 below. 536 8.2.1. Network services 537 8.2.1.1. Identification of Interfaces 539 Configuration information that relates to identification deals with 540 the namespace of the interfaces of a network equipment. This naming 541 scheme describes the properties of an interface, and must take into 542 account all the parameters that are required to correctly configure 543 an interface. The following information MUST be provided: 545 A name, with a generic syntax not related to a specific vendor. The 546 name can define the media type of the interface; 547 Depending on the media type, further information MAY be added (link 548 mode, MTU, speed...); 550 - Optionally, a logical descriptor. Depending on the media type 551 it can be relevant to have a logical descriptor (for VLANs 552 declared on Ethernet interfaces, for instance). In this case 553 the encapsulation type must be provided; 555 - Optionally, a description field giving general information 556 about the interface (i.e. ôOC192 link from LA to SFö) 558 8.2.1.2. Quality of Service (QoS) 560 IP services are provided with a level of quality that MAY be 561 guaranteed (either qualitatively or quantitatively) by any means 562 appropriate. QoS policies SHOULD be dynamically enforced according to 563 a data model that will accurately reflect all the elementary QoS 564 capabilities that MAY be configured and activated to enforce such 565 policies. 567 For instance, in the case of the activation of the DiffServ QoS model 568 within a network infrastructure, the participating routers should be 569 provided with the appropriate parameters. 571 8.2.1.3. Security 573 The protocol architecture MUST provide security functions that 574 provide source authentication, integrity and confidentiality of 575 configuration information. The security functions MUST be activated, 576 whatever the contents of the payload. 578 In order to protect device accesses, the configuration architecture 579 MUST provide a filtering / fire-walling access scheme that would 580 allow to control remote and in-band accesses (i.e. console security 581 rules, access listsà) 583 8.2.1.4. Applications 585 Network devices usually run network functions that allow activation 586 of specific services, like HTTP, BOOTP, DHCP, SYSLOG ... 587 Such devices must therefore be provided with the relevant information 588 related to these services: 590 - the ability to enable or disable the service; 591 - the mandatory parameters for each of the service. 593 8.2.2. Forwarding services 594 8.2.2.1. Routing and Forwarding Configuration Information 596 Routing and forwarding configuration information deals with the 597 decision criteria that should be taken by a participating device to 598 forward an incoming IP datagram, according to a given routing policy. 599 From this perspective, the participating devices should be provided 600 with the following information: 602 - In the case of the activation of dynamic routing protocols for the 603 computation and the selection of routes that will be considered 604 for forwarding traffic, the participating routers SHOULD be 605 provided with the relevant metric information so that the routers 606 (dynamically) assign the metric values accordingly, 608 - In the case where the traffic is to be conveyed across domains, 609 the participating devices should be provided with the relevant 610 BGP-4 (Border Gateway Protocol, version 4)-based reachability 611 information, including the BGP-4 attribute-related information 612 that will be taken into account by the route selection process of 613 the router to decide where to forward the corresponding traffic, 615 - Also, the participating routers should be provided with the 616 configuration information related to any static route that may 617 identify specific next hops to reach a given destination prefix. 619 8.2.2.2. Traffic Engineering Configuration Information 621 Traffic engineering is an important task of configuration management: 622 within this context, the participating devices should be provided 623 with the configuration information that will help them to choose the 624 appropriate routes that lead to a set of destinations, according to 625 specific constraints. 627 These constraints may be expressed in terms of time duration (e.g. 628 the use of a traffic-engineered route on a weekly basis), traffic 629 characterization (e.g. all the IP multicast traffic should be 630 conveyed by a specific route), security concerns (e.g. use IPSec [9] 631 tunnels whenever possible), and/or QoS considerations (e.g. EF 632 (Expedited Forwarding, [10])-marked traffic should always use a 633 subset of activated and well-identified routes). 635 The enforcement of an IP traffic engineering policy would therefore 636 yield the use of specific routes that will be dynamically computed 637 and selected according to the aforementioned type of configuration 638 information. 640 8.2.2.3. Configuration Information for Tunnel Design and Activation 641 8.2.2.4. Tunnel Identification Information 643 The identification of a tunnel should be globally unique, especially 644 if the tunnel is to be established and activated across autonomous 645 systems. The tunnel identification schemes (e.g. endpoint numbering) 646 should be left to service providers, given that the corresponding 647 formalism may be commonly understood, whatever the number of 648 autonomous systems the tunnel may cross. 650 The tunnel identification information should at least be composed of 651 the tunnel endpoint identification information. The tunnel 652 identification information may also be composed of an informal 653 description of the tunnel, e.g. the purpose of its establishment, the 654 customer(s) who may use this tunnel, etc. 656 There may be cases where this additional information is irrelevant, 657 e.g. in the case where the tunnel has been designed to convey public 658 Internet traffic, where a user wishes to access IP multicast-based 659 services through non-multicast capable clouds. 661 8.2.2.5. Tunneling Protocol Configuration Information 663 Any participating device MUST be provided with the configuration 664 information related to the tunneling technique to be used for the 665 establishment and the activation of the tunnel. Such techniques 666 include Generic Routing Encapsulation (GRE, [11]), IP Secure in 667 tunnel mode (IPSec), Layer 2 Tunneling Protocol (L2TP, [12]), etc. 669 8.2.3. Management services 670 8.2.3.1. Fault Management 672 Fault management is one of the critical points when managing a given 673 service. Indeed, an operator MAY deploy means to detect fault 674 occurring in its network and has pre-configured policies that SHOULD 675 be enforced by participating devices to limit the impact on the 676 quality of service. 678 Mechanisms to monitor and report the incidents that occurred to the 679 service management SHOULD be independent of the configuration 680 protocol. 682 8.2.3.2. Configuration Management 684 Configuration management is responsible for the provisioning of 685 configuration information to produce a service. Errors during a 686 configuration procedure could impact the availability of a given 687 service offering, while consistency checks are mandatory so as to 688 correctly enforce a configuration policy. 690 The following requirements have been identified: 692 - Data provisioning SHOULD be as automated as possible 694 - An operator SHOULD have means to detect and diagnose 695 configuration errors 697 - An operator SHOULD deploy means to check the consistency of the 698 configuration information forwarded to the participating 699 devices, especially when a whole range of IP services can be 700 delivered upon subscription requests. 702 - An operator MAY simulate the impact of the enforcement of a 703 given configuration policy on its services before delivering 704 such information to the participating devices. 706 8.2.3.3. Performance Management 708 Performance management is mainly deals with the monitoring of the 709 network and the status of the services. 710 The performance of a configuration policy/architecture will be 711 studied in the next version of this draft. 713 8.2.3.4. Security Management 715 8.2.3.4.1. Device Authentication 717 It MUST be possible to activate mutual authentication between a 718 participating device and a centralized entity that is responsible for 719 instantiating and forwarding configuration data to these 720 participating devices. The authentication MUST be checked before 721 exchanging any configuration data to prevent DoS (Denial of Service) 722 attacks. 724 8.2.3.4.2. Integrity of configuration information 726 Two types of integrity MUST be provided. The first one MAY be done at 727 the network layer, e.g. by using the IPsec protocol suite. It will 728 protect each IP datagram, exchanged between a participating device 729 and the configuration management platform(s), from malicious 730 modification. The second one SHOULD protect the configuration data at 731 the application layer (e.g. the entire file configuration is 732 integrity protected). 734 8.2.3.4.3. Confidentiality of exchanged data 736 The participating device SHOULD provide security functions that 737 provide confidentiality. The encryption algorithms MUST be selectable 738 manually and/or automatically. The encryption algorithms MUST be the 739 standard ones. 741 8.2.3.4.4. Key management 743 The configuration system MUST provide a scalable key management 744 scheme. The number of keys to be managed must be at most linearly 745 proportional to the number of the devices. 747 8.2.3.4.5. Log of connections 749 The participating device MUST log all configuration connections. At 750 least the following information must be provided: 752 - Identity of the device which provided the configuration 753 information, 754 - Date of the connection, 755 - Identity of the user that has launched the configuration process, 756 - Version of the configuration data has been enforced. 758 8.2.3.4.6. Profiles 760 The configuration system MUST allow the definition and the activation 761 of several privilege levels. Each level could be associated to a set 762 of administrative functions. And each configuration administrator 763 could be assigned a specific privileged access level to perform a 764 (possibly limited) set of configuration tasks. 766 9. Security Considerations 768 This draft reflects a set of requirements as far as the design and 769 the enforcement of configuration policies are concerned for 770 (automated) service subscription, delivery and exploitation. As such, 771 the document addresses some security concerns that have been depicted 772 in section 9.2.3.5, and that SHOULD be taken into account when 773 considering the specification of a protocol that will convey 774 configuration information, as well as configuration information 775 itself. 777 10. References 779 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 780 9, RFC 2026, October 1996. 782 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 783 Levels", BCP 14, RFC 2119, March 1997 785 [3] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 786 and Applicability Statements for Internet-Standard Management 787 Framework", RFC 3410, December 2002. 789 [4] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. 790 Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 791 2748, January 2000. 793 [5] Chan, K., Durham, D., Gai, S., Herzog, S., McCloghrie,K., 794 Reichmeyer, F., Seligson, J., Smith, A. and R. Yavatkar, "COPS 795 Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. 797 [6] Distributed Management Task Force, "Common Information Model 798 (CIM) Specification Version 2.2", DSP 0004, June 1999. 800 [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of 801 Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 802 1999. 804 [8] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., 805 Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy 806 Provisioning Information (SPPI)", RFC 3159, August 2001. 808 [9] Atkinson R., "Security Architecture for the Internet Protocol", 809 RFC 2401, August 1998. 811 [10] Davie, B., Charny, A., Bennett, J.C.R., Benson, K., Le Boudec, 812 J.Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An 813 Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 814 2002. 816 [11] Farinacci, D., et al., "Generic Routing Encapsulation (GRE)", 817 RFC 2784, March 2000. 819 [12] Townsley, W., et al., "Layer Two Tunneling Protocol "L2TP"", RFC 820 2661, August 1999. 822 11. Acknowledgments 824 12. Authors' Addresses 826 Mohamed Boucadair 827 France Telecom R & D 828 42, rue des Coutures 829 14000 Caen, 830 France 831 Phone: 33 2 31 75 92 31 832 Email: mohamed.boucadair@francetelecom.com 833 Christian Jacquenet 834 France Telecom Long Distance 835 3 Avenue Fran‡ois Ch‚teau 836 35901 Rennes Cedex, 837 France 838 Phone: 33 2 99 87 63 31 839 Email: christian.jacquenet@francetelecom.com 841 Mohammed Achemlal 842 France Telecom R & D 843 42, rue des Coutures 844 14000 Caen, France 845 Phone: 33 2 31 75 92 28 846 Email: mohammed.achemlal@francetelecom.com 848 Yan Adam 849 France Telecom R&D LANNION 850 2 Avenue Pierre Marzin 851 22307 Lannion Cedex 852 France 853 Phone: 33 2 96 05 29 19 854 Email: yan.adam@francetelecom.com 856 Intellectual Property Statement 858 The IETF takes no position regarding the validity or scope of any 859 Intellectual Property Rights or other rights that might be claimed to 860 pertain to the implementation or use of the technology described in 861 this document or the extent to which any license under such rights 862 might or might not be available; nor does it represent that it has 863 made any independent effort to identify any such rights. Information 864 on the procedures with respect to rights in RFC documents can be 865 found in BCP 78 and BCP 79. 867 Copies of IPR disclosures made to the IETF Secretariat and any 868 assurances of licenses to be made available, or the result of an 869 attempt made to obtain a general license or permission for the use of 870 such proprietary rights by implementers or users of this 871 specification can be obtained from the IETF on-line IPR repository at 872 http://www.ietf.org/ipr. 874 The IETF invites any interested party to bring to its attention any 875 copyrights, patents or patent applications, or other proprietary 876 rights that may cover technology that may be required to implement 877 this standard. Please address the information to the IETF at 878 ietf-ipr@ietf.org. 880 Disclaimer of Validity 882 This document and the information contained herein are provided on an 883 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 884 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 885 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 886 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 887 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 888 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 890 Copyright Statement 892 Copyright (C) The Internet Society (2004). This document is subject 893 to the rights, licenses and restrictions contained in BCP 78, and 894 except as set forth therein, the authors retain all their rights.