idnits 2.17.1 draft-jacquenet-tunman-reqts-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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (April 2003) is 7681 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2002 (ref. '7') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2401 (ref. '10') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 1771 (ref. '12') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2598 (ref. '13') (Obsoleted by RFC 3246) ** Obsolete normative reference: RFC 2138 (ref. '14') (Obsoleted by RFC 2865) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jacquenet 3 Internet Draft France Telecom R&D 4 Document: draft-jacquenet-tunman-reqts-02.txt October 2002 5 Category: Informational 6 Expires April 2003 8 Requirements for dynamic tunnel configuration 9 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 RFC 2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 In today's Internet, tunnels are established and activated to provide 33 a facility for conveying a specific traffic from one point to 34 another, or from one point to several others. This draft aims at 35 describing the requirements for the specification and the 36 standardization of the configuration information that will be used to 37 define, establish, activate and maintain such facilities. 39 Table of Contents 41 1. Introduction................................................2 42 2. Conventions used in this document...........................3 43 3. Changes since the previous version of the draft.............3 44 4. Terminology.................................................3 45 5. A proposed taxonomy for classifying tunnel 46 configuration information.................................4 47 6. Tunnel configuration information requirements...............6 48 6.1. Architectural considerations................................6 49 6.1.1. Tunnel identification information...........................6 50 6.1.2. Tunneling protocol configuration information................6 51 6.1.3. Routing and forwarding configuration information............6 52 6.1.4. Traffic engineering configuration information...............7 53 6.2. Quality of service considerations...........................7 54 6.2.1. Tunnel configuration information for QoS policy 55 enforcement...............................................7 56 6.2.2. QoS parameters as (part of) tunnel configuration 57 information...............................................8 58 6.3. Security considerations.....................................8 59 6.4. Management considerations...................................9 60 7. Functional requirements for a protocol to convey tunnel 61 configuration information.................................9 62 8. Consistency with some IETF standardization efforts.........10 63 9. Security Considerations....................................10 64 10. Acknowledgements...........................................11 65 11. References.................................................11 66 12. Author's Address...........................................11 68 1. Introduction 70 In today's Internet, tunnels are established and activated to provide 71 a facility for conveying a specific traffic from one point to 72 another. The use of such facilities is motivated by the deployment of 73 a range of IP service offerings, like IP VPN (Virtual Private 74 Networks, [2]) or IP multicast-based services ([3]), such as 75 videoconferencing. 77 The implicit complexity of these value-added services is due to the 78 manipulation of a large set of configuration information for the 79 actual engineering, establishment, activation and maintenance of such 80 tunnels. 82 This configuration information includes the definition of forwarding 83 and routing schemes (i.e. what kind of traffic should be conveyed by 84 the tunnel, to which destination, etc.), security considerations 85 (identification and authentication of the users who are granted to 86 access the tunnel facility), as well as Quality of Service (QoS) 87 considerations, like the DSCP (DiffServ Code Point, [4]) marking 88 associated to the IP datagrams that are entitled to be forwarded 89 through the tunnel. 91 Because of the wide variety of devices that may support the 92 aforementioned capabilities, it is important that an interface exists 93 such that tunnel management configuration information can be 94 dynamically provided in a vendor-independent manner, and for a number 95 of services, whatever the underlying technology, and whatever the 96 nature of such services. From this standpoint, this document 97 complements the statements introduced by RFC 3139 ([5]). 99 This document is organized into the following sections: 101 - Section 4 is the terminology section of the document, where 102 several basic notions have been defined, 103 - Section 5 aims at defining a taxonomy for the various kinds of 104 configuration information that is needed to design, establish, 105 activate and maintain a tunnel, 106 - Section 6 proposes a list of requirements according to the above- 107 mentioned taxonomy, 108 - Finally, section 7 aims at describing the functional requirements 109 for a communication protocol that would be a privileged vector for 110 conveying tunnel configuration information. 112 2. Conventions used in this document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [6]. 118 3. Changes since the previous version of the draft 120 This new version of the draft introduces the following changes: 122 - Slight re-wording of the abstract section, 124 - Correction of remaining typos. 126 4. Terminology 128 This section aims at providing a set of basic definitions for the 129 terms that will be used by this document. 131 - Endpoint: one of the extremities of a tunnel. 133 - Participating device: any networking equipment that will 134 participate in the establishment, the activation and the 135 maintenance of a tunnel. Such devices may include routers and 136 hosts, whatever the tunneling technique to be used for tunnel 137 construction. 139 - Subscriber: A subscriber (or a customer) is a legal 140 representative who has the (legal) ability to subscribe to a 141 service offering. 143 - Tunnel: a tunnel is a transport facility that is designed to 144 convey (IP) data traffic between one endpoint and another (point- 145 to-point tunnels), or between one endpoint and several others 146 (point-to-multipoint tunnels). Tunnels can be used for different 147 purposes, e.g.: 149 - Access IP multicast networks over IP clouds that do not 150 support multicast forwarding capabilities, 151 - Access IPv6 networks over IPv4 clouds, 152 - Deploy IP Virtual Private Networks, 153 - Deploy Mobile IP ([7]) architectures. 155 - Tunnel activation: the configuration tasks that position a tunnel 156 facility into an activated state, so that it can be used to 157 convey traffic. Obviously, a tunnel must not (and, hopefully, 158 cannot) be activated before it has been established. 160 - Tunnel establishment: all the configuration tasks that lead to 161 the configuration of a tunnel facility. Once the tunnel is 162 established, it needs to be activated in order to be able to 163 convey traffic. 165 - Tunnel maintenance: the period of time during which a tunnel 166 facility remains activated. 168 - User: A user is an entity (a human being or a process, from a 169 general perspective) who has been identified (and possibly 170 authenticated) by a service provider, and whose traffic will be 171 conveyed through a tunnel facility, according to his associated 172 rights and duties. 174 - VPN: Virtual Private Network. A collection of switching resources 175 (e.g. routers) and transmission resources that will be used over 176 an IP backbone thanks to the establishment and the activation of 177 tunnels. These tunnels will convey the IP traffic that 178 characterizes the data oriented-communication service of a 179 customer (VPNs that are designed to support intranet-based 180 applications) or a set of customers (VPNs that are designed to 181 support extranet-based applications). Thus, IP VPN networks are 182 an applicability example of tunnel configuration and management 183 activities. 185 5. A proposed taxonomy for classifying tunnel configuration information 187 For the last decade, the deployment of value-added IP service 188 offerings has yielded the tremendous development of complex 189 configuration information, from dynamic IP address assignment to 190 security management, not to mention routing strategies and QoS policy 191 enforcement. 193 There is a wide variety of advanced IP service offerings - IP VPNs, 194 IP multicast-based services, multimedia services like IP 195 videoconferencing - that rely upon the use of tunnels, because of 196 various motivations: 198 1. The need for isolating the traffic that corresponds to the 199 deployment of these services from other traffics, 201 2. The need for preserving the confidentiality of the traffic that 202 will be conveyed over a public IP infrastructure, 203 3. The need for enforcing specific forwarding and routing schemes, 204 because of the (non)-support of specific capabilities such as IP 205 multicast, 206 4. The need for servicing customers according to specific QoS 207 parameters, 208 5. Etc. 210 Because of the crucial importance of such tunnels, it seems 211 reasonable to clearly identify what are the elementary components of 212 the configuration information for the design, the establishment, the 213 activation and the maintenance of these transport facilities. To do 214 so, this document proposes the following taxonomy, while the next 215 sub-sections will elaborate on each of these domains. 217 - Architectural considerations: the corresponding tunnel 218 configuration information refers to the very basic information 219 that is needed for the establishment and the activation of the 220 tunnel - namely the identification of the endpoints, the 221 forwarding and routing schemes (including possible traffic 222 engineering capabilities) to be processed by the devices that will 223 participate in the forwarding of the traffic conveyed by the 224 tunnel. Such information may also include the identification of 225 the tunnel facility itself. 227 - QoS considerations: the corresponding configuration information 228 deals with any QoS parameter that may characterize the tunnel. 229 This may include the classification of the traffic that will be 230 forwarded through the tunnel, the marking parameters associated to 231 such traffic, the Per-Hop Behaviors (PHB, [8]) that will be 232 enforced by the participating routers, etc. 234 - Security considerations: any tunnel that may be established and 235 activated by a service provider to convey a specific traffic 236 yields the need for identification and authentication 237 capabilities. Such capabilities relate to the tunnel users' 238 identification and authentication, but also to the possible 239 identification and authentication of the resources that 240 participate in the establishment, the activation and the 241 maintenance of a tunnel. Indeed, the establishment and the 242 activation of a tunnel between two or more endpoints imply that 243 the corresponding devices are granted for supporting tunnel 244 capabilities, but also for any related capability, including route 245 announcement. 247 - Management considerations: it is assumed that the exploitation of 248 tunnels is part of the basic management tasks, and there is 249 therefore a need for collecting all the relevant statistical 250 information about the tunnels that are under establishment, those 251 that are under activation, those that are up and running, etc. 253 Thus, the tunnel configuration information can be classified into the 254 following domains: 256 1. Architecture, 257 2. Quality of service, 258 3. Security, 259 4. Management. 261 The following sections provide elaboration on the corresponding 262 requirements. 264 6. Tunnel configuration information requirements 266 6.1. Architectural considerations 268 6.1.1. Tunnel identification information 270 The identification of a tunnel should be globally unique, especially 271 if the tunnel is to be established and activated across autonomous 272 systems. The tunnel identification schemes (e.g. endpoint numbering) 273 should be left to service providers, given that the corresponding 274 formalism may be commonly understood, whatever the number of 275 autonomous systems the tunnel may cross. 277 The tunnel identification information should at least be composed of 278 the tunnel endpoint identification information. The tunnel 279 identification information may also be composed of an informal 280 description of the tunnel, e.g. the purpose of its establishment, the 281 customer(s) who may use this tunnel, etc. 283 There may be cases where this additional information is irrelevant, 284 e.g. in the case where the tunnel has been designed to convey public 285 Internet traffic, where a user wishes to access IP multicast-based 286 services through non-multicast capable clouds. 288 6.1.2. Tunneling protocol configuration information 290 Any participating device must be provided with the configuration 291 information related to the tunneling technique to be used for the 292 establishment and the activation of the tunnel. Such techniques 293 include Generic Routing Encapsulation (GRE, [9]), IP Secure in tunnel 294 mode (IPSec, [10]), Layer 2 Tunneling Protocol (L2TP, [11]), etc. 296 6.1.3. Routing and forwarding configuration information 298 Routing and forwarding configuration information deals with the 299 decision criteria that should be taken by a participating device to 300 forward an incoming IP datagram into the tunnel, according to a given 301 tunnel routing policy. From this perspective, the participating 302 devices should be provided with the following information: 304 - In the case of the activation of dynamic routing protocols for the 305 computation and the selection of routes that will be considered 306 for forwarding traffic through the tunnel, the participating 307 router should be provided with the relevant metric information so 308 that the router (dynamically) assigns the metric values 309 accordingly, 311 - In the case where the tunnel is expected to convey traffic across 312 domains, the participating devices should be provided with the 313 relevant BGP-4 (Border Gateway Protocol, version 4, [12])-based 314 reachability information, including the BGP-4 attribute-related 315 information that will be taken into account by the route selection 316 process of the router to decide whether the corresponding traffic 317 should be forwarded through the tunnel or not, 319 - Also, the participating routers should be provided with the 320 configuration information related to any static route that may 321 identify a tunnel endpoint as the next hop to reach a given 322 destination prefix. 324 6.1.4. Traffic engineering configuration information 326 Traffic engineering is an important task of tunnel configuration 327 management: within this context, the participating devices should be 328 provided with the configuration information that will help them to 329 choose the appropriate tunnel that leads to a given destination, 330 according to specific constraints and/or requirements. 332 These constraints and/or requirements may be expressed in terms of 333 time duration (e.g. the use of a tunnel on a weekly basis), traffic 334 characterization (e.g. all the IP multicast traffic should be 335 conveyed by a specific tunnel), security concerns (e.g. use IPSec 336 tunnels whenever possible), and/or QoS considerations (e.g. EF 337 (Expedited Forwarding, [13])-marked traffic should always use a 338 subset of activated and well-identified tunnels). 340 The enforcement of an IP traffic engineering policy would therefore 341 yield the use of specific tunnels that will be constructed according 342 to the aforementioned type of configuration information. 344 6.2. Quality of service considerations 346 Tunnels may be established to enforce a QoS policy, and/or tunnels 347 may be established according to QoS parameters. 349 6.2.1. Tunnel configuration information for QoS policy enforcement 351 Service providers may decide to rely upon the use of tunneling 352 techniques to enforce a given QoS policy within a domain. For 353 example, the implementation of an EF PHB by the routers of a DiffServ 354 domain may be tightly related to the establishment and the activation 355 of (a set of) tunnels that will be dedicated to the transportation of 356 EF-marked traffic over the whole domain. 358 Therefore, the participating devices should be provided with the PHB- 359 related configuration information, DSCP marking, policing and 360 scheduling configuration information that will be associated to the 361 establishment of such tunnels. 363 6.2.2. QoS parameters as (part of) tunnel configuration information 365 On the other hand, a tunnel may be established and activated once the 366 associated QoS-related information has been provisioned to the 367 participating devices. Without any specific QoS policy consideration, 368 such devices should indeed be provided with the configuration 369 information that may consist of: 371 - The DSCP marking associated to the datagrams that may be conveyed 372 by the tunnel, 374 - The scheduling algorithm parameters that will be used by the 375 participating devices to enforce a tunnel-based buffering policy 376 accordingly, 378 - The traffic conditioning algorithm parameters that will be used by 379 the participating devices to enforce a tunnel-based traffic 380 shaping policy accordingly, 382 - Etc. 384 While these parameters may very well be the same as those that have 385 been identified in sub-section 6.2.1.of this document, the actual 386 usage of these parameters as tunnel configuration information may 387 dramatically differ, depending on domain-wide policy enforcement 388 considerations, or locally-processed configuration information. 390 6.3. Security considerations 392 This section aims at listing the basic requirements for the 393 provisioning of the configuration information related to the security 394 associated to the establishment and the activation of tunnels. By 395 "security", this draft basically means: 397 - The identification and the authentication of the users who may 398 access the tunnel facility, 400 - The identification and the authentication of the switching 401 resources that will not only participate in the establishment and 402 the activation of the tunnel, but also in the route information 403 propagation that may be used by the participating devices to 404 appropriately forward traffic into the tunnels, 406 - Finally, the preservation of the confidentiality of the 407 information that may be conveyed by the tunnel. 409 Therefore, the participating devices should be provided with all the 410 configuration information related to the aforementioned topics. This 411 does not mean that the routers will have to maintain a dynamically 412 updated user database, but rather, they should be provided with the 413 following configuration information: 415 - The knowledge of the IP networks that may exchange data through 416 the tunnel and/or the configuration information needed for the 417 activation of an identification/authentication mechanism such as 418 RADIUS (Remote Authentication Dial-In User Service, [14]), 420 - The knowledge of the participating devices that support the other 421 endpoint(s) of the tunnel and possibly the configuration 422 information related to the activation of a mechanism for 423 identifying and authenticating such peers (based upon the use of 424 an MD5 (Message Digest type 5, [15]) digital signature, for 425 example), 427 - The knowledge of the configuration information needed in the case 428 of using encryption techniques. 430 6.4. Management considerations 432 Service providers who rely upon the use of tunneling techniques for 433 the deployment of a range of IP service offerings will naturally have 434 requirements as far as the usage of these tunnels is concerned. From 435 this perspective, the participating devices should be able to give 436 access to any statistical information related to: 438 - The volume of traffic that has been conveyed by the tunnel on a 439 given period of time, including a distinction between incoming and 440 outgoing traffic, 442 - The volume of tunneled traffic that has been dropped by the 443 participating devices on a given period of time, 445 - The IPPM (IP Performance Metrics, [16])-related information that 446 is relevant to the tunnel usage: such information includes the 447 one-way packet delay, the inter-packet delay variation, etc. 449 7. Functional requirements for a protocol to convey tunnel configuration 450 information 452 Although this document focuses on the motivation for providing 453 configuration information related to tunnel establishment, activation 454 and maintenance, it is assumed that this configuration information 455 should be provided to the participating devices by means of a 456 communication protocol that would be used between the aforementioned 457 participating devices and a presumably centralized entity that would 458 aim at storing, maintaining and updating this configuration 459 information, as well as making appropriate decisions at the right 460 time and under various conditions. 462 This communication protocol should have the following 463 characteristics: 465 1. The protocol should use a reliable transport mode, given the 466 importance of configuration information, 467 2. The protocol architecture should provide a means for dynamically 468 provision the configuration information to the participating 469 devices, so that it may introduce/contribute to a high level of 470 automation in the actual negotiation and invocation of the 471 corresponding IP service offerings (e.g. the configuration of 472 thousands of IPSec tunnels for the deployment of an IP VPN for a 473 large banking company should NOT be manual anymore), 474 3. The protocol should support a reporting mechanism that may be 475 used for statistical information retrieval, 476 4. The protocol should support the appropriate security mechanisms 477 to provide some guarantees as far as the preservation of the 478 confidentiality of the configuration information is concerned. 480 8. Consistency with some IETF standardization efforts 482 It is required that the specification work that may be launched 483 because of an interest of the IETF community for this tunnel 484 configuration topic, should be as consistent as possible with any 485 work item of any relevant IETF working group that has identified 486 tunneling techniques as a means for deploying a specific architecture 487 and/or conveying IP traffic. Such working groups include ppvpn and 488 mobileip. 490 9. Security Considerations 492 This draft has identified a set of configuration information that 493 would be required for the establishment, the activation and the 494 management of tunnels to be deployed over public IP infrastructures. 495 As such, it raises the issue of the security associated to the 496 provisioning of such information, by means of a protocol whose some 497 basic characteristics have been discussed in section 7. 499 There are also security concerns associated with the propagation of 500 the tunnel provisioning data to the network elements that will 501 participate in the tunnel establishment and activation procedures, 502 and also to the customers (including service providers within an 503 inter-domain context) who may access such data. 505 A basic recommendation therefore consists in using the resources of 506 the IPSec protocol suite whenever possible. 508 10. Acknowledgements 510 The author would like to thank the "tunman" ([17]) community for the 511 useful discussion that yielded the publication of this draft. 513 11. References 515 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 516 BCP 9, RFC 2026, October 1996. 517 [2] Gleeson, B. et al., "A Framework for IP Based Virtual Private 518 Networks", RFC 2764, February 2000. 519 [3] Quinn, B., Almeroth, K., "IP Multicast Applications: Challenges 520 and Solutions", RFC 3170, September 2001. 521 [4] Nichols K., Blake S., Baker F., Black D., "Definition of the 522 Differentiated Services Field (DS Field) in the IPv4 and IPv6 523 Headers", RFC 2474, December 1998. 524 [5] Sanchez, L., McCloghrie, K., Saperia, J., "Requirements for 525 Configuration Management of IP-based Networks", RFC 3139, June 526 2001. 527 [6] Bradner, S., "Keywords for use in RFCs to Indicate Requirement 528 Levels", BCP 14, RFC 2119, March 1997. 529 [7] Perkins, C., et al., "IP Mobility Support", RFC 2002, October 530 1996. 531 [8] Blake, S., et al., "An Architecture for Differentiated 532 Services", RFC 2475, December 1998. 533 [9] Farinacci, D., et al., "Generic Routing Encapsulation (GRE)", 534 RFC 2784, March 2000. 535 [10] Atkinson R., "Security Architecture for the Internet Protocol", 536 RFC 2401, August 1998. 537 [11] Townsley, W., et al., "Layer Two Tunneling Protocol "L2TP"", 538 RFC 2661, August 1999. 539 [12] Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC 540 1771, March 1995. 541 [13] Jacobson, V., et al., "An Expedited Forwarding PHB", RFC 2598, 542 June 1999. 543 [14] Rigney, C., et al., "Remote Authentication Dial In User Service 544 (RADIUS)", RFC 2138, April 1997. 545 [15] Rivest, R., " The MD5 Message-Digest Algorithm", RFC 1321, 546 April 1992. 547 [16] Paxson, V. et al., "Framework for IP Performance Metrics", RFC 548 2330, May 1998. 549 [17] tunman@external.cisco.com. 551 12. Author's Address 553 Christian Jacquenet 554 France Telecom Long Distance 555 IAP/CTO 556 3, rue Fran�ois Chateau 557 35000 Rennes 558 France 559 Phone: +33 2 99 87 63 31 560 E-Mail: christian.jacquenet@francetelecom.com 562 Full Copyright Statement 564 Copyright(C) The Internet Society (2002). All Rights Reserved. 566 This document and translations of it may be copied and furnished to 567 others, and derivative works that comment on or otherwise explain it 568 or assist its implementation may be prepared, copied, published and 569 distributed, in whole or in part, without restriction of any kind, 570 provided that the above copyright notice and this paragraph are 571 included on all such copies and derivative works. However, this 572 document itself may not be modified in any way, such as by removing 573 the copyright notice or references to the Internet Society or other 574 Internet organizations, except as needed for the purpose of 575 developing Internet standards in which case the procedures for 576 copyrights defined in the Internet Standards process must be 577 followed, or as required to translate it into languages other than 578 English. 580 The limited permissions granted above are perpetual and will not be 581 revoked by the Internet Society or its successors or assigns. 583 This document and the information contained herein is provided on an 584 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 585 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 586 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 587 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 588 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.