idnits 2.17.1 draft-ishimatsu-ipo-lightpath-scrty-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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 (March 2001) is 8441 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. 'ITU-ASTN' -- Possible downref: Non-RFC (?) normative reference: ref. 'TMM' -- Possible downref: Non-RFC (?) normative reference: ref. 'ASON-UNI' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft 4 Expiration Date: September 2001 6 Hirokazu Ishimatsu Zhi-Wei Lin 7 Shinya Tanaka Yangguang Xu 8 Japan Telecom Lucent Technologies 10 Juergen Heiles Yang Cao 11 Siemens AG Sycamore Networks 13 March 2001 15 Security Requirements for Lightpath Services 17 draft-ishimatsu-ipo-lightpath-scrty-00.txt 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 Many efforts have been introduced to achieve lightpath services 43 using optical cross-connects (OXCs). This document surveys security 44 prerequisites to be considered when lightpath services are offered 45 to users. 47 Section 5 discussed prerequisites for lightpath services. Section 6 48 discussed required actions for the prerequisites that are described 49 in section 5. Section 7 discussed security requirements for possible 50 business models of lightpath services. 52 Table of Contents 54 1 Specification ............................................. 2 55 2 Acronyms .................................................. 2 56 3 Introduction .............................................. 2 57 4 Lightpath services ........................................ 3 58 5 Prerequisites for lightpath services ...................... 3 59 6 Required actions for prerequisites ........................ 4 60 7 Security requirements for business models of lightpath 61 services .................................................. 6 62 8 Acknowledgement ........................................... 7 63 9 References ................................................ 7 64 10 Security Considerations ................................... 7 65 11 Authors' Addresses ........................................ 7 67 1. Specification 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119. 73 2. Acronyms 75 ASTN Automatic switched Transport Network 76 BIP Bit Interleaved Parity 77 CPE Customer Premises Equipment 78 CRC Cyclic Redundancy Check 79 DoS Denial of Service 80 FEC Forward Error Correction 81 ISP Internet Service Provider 82 NMS Network Management System 83 OTN Optical Transport Network 84 OXC Optical Cross-connect 85 SLA Service Level Agreement 87 3. Introduction 89 In these days, traffic demand has been increasing rapidly because of 90 the explosive spread of the internet and telecommunication has been 91 getting more and more essential to our daily life. Under such a 92 circumstance, it is obvious that the layer 1 optical network, on 93 which data is carried, is important as the backbone of 94 telecommunication. Therefore layer 1 optical network should be 95 reliable and secured in order to function as the necessary 96 infrastructure. 98 In addition to that, it is often said that generation shift in layer 99 1 optical network is necessary to deal with the explosion of traffic 100 demand. One of such next generation layer 1 network is ASTN 101 (Automatic Switched Transport Network)[ITU-ASTN]. ASTN is able to 102 supply on-demand lightpath provisioning by users and offer users 103 lightpath services. This means the layer 1 connection setup is 104 controlled by users. Therefore it needs very severe accounting, 105 call acceptance, billing, etc. 107 The remainder of this draft claims security requirements for 108 lightpath services. 110 4.Lightpath services 112 Lightpath services are to offer users end-to-end connectivity. These 113 connectivity may be in the form of SONET/SDH rate services, emerging 114 OTN-based services, and transparent wavelength services. 116 5. Security prerequisites for lightpath services 118 The following items are related to the security aspect of lightpath 119 services 121 5.1 Confidentiality 123 A lightpath should be disclosed only to authorized persons, entities 124 and processes at authorized time and in the authorized manner. 126 5.2 Integrity 128 The characteristics of data and information that a lightpath carries 129 should be accurate and complete. While a lightpath is offered, the 130 presentation of accuracy and completeness should be kept. This 131 characteristic is inherent to the network design of each service 132 provider. 134 5.3 Serviceability 136 A lightpath should be available on demand by an authorized entity. 137 An authorized entity should be able to request service for a light 138 path on demand. 140 5.4 Accountability 142 It should be ensured that the billable actions of an entity can be 143 allocatable to the correct account. 145 5.5 Authenticity 147 It should be ensured that the identity of a subject or resource is 148 the one claimed authenticity. Authenticity applies to entities such 149 as users, processes, systems and information. 151 5.6 Reliability/Availability 153 Intended behavior and results should be consistent with that agreed 154 between the authorized entity and the service provider. 156 5.7 Ethics 158 Lightpath services should be provided and used in such a manner that 159 the rights and legitimate interests of others are respected. 161 6. Required actions for prerequisites 163 6.1 Confidentiality 165 lightpaths on each link are isolated by wavelengths. Therefore 166 confidentiality of each lightpath is naturally kept. Encryption of 167 data at application level can add additional confidentiality to a 168 lightpath. As the connection-oriented world does not have issues 169 with merging of packets, user traffic isolation and thus 170 confidentiality mechanisms are not as critical. However, 171 misconnection may still occur due to defected cross-connects by 172 equipment fault or miss-destination by human error; thus a mechanism 173 to ensure no misconnection is needed. One example of this mechanism 174 may be making lightpath requestors send their IDs to lightpath 175 receivers and allowing lightpath receivers to decide if they accept 176 the lightpath by the ID sent. 178 6.2 Integrity 180 Perfect integrity is a trade-off against infinite-cost. Integrity 181 requirements should be quantified, and those quantified requirements 182 should be kept less than the thresholds set by a lightpath service 183 provider in practice. 185 Some performance monitoring scheme should be done in order to 186 quantify integrity requirements. At wavelength level, performance can 187 be monitored by analog measurements such as S/N, toned modulation 188 monitor[TMM], and etc. In the case of transparent end-to-end 189 lightpath service where optical signal is not terminated digitally 190 within a service provider's domain, analog type of measurements 191 should be performed. At upper layers, where optical signal is 192 terminated digitally, Digital performance monitoring, such as FEC, 193 BIP, CRC and etc., can be done. For the emerging OTN-based network, 194 the tandem connection monitoring may be used to provide flexible 195 monitoring points across multiple sub-networks. Multiple performance 196 monitoring schemes at multiple layers may be needed to keep integrity 197 of data. Choice of performance monitoring scheme depends on service 198 provider's policy and technical constraints. 200 6.3 Serviceability 202 Any lightpath service provider cannot guarantee 100% 203 serviceability since denial of service (DoS) can be occurred by 204 network failures, customer premises equipment (CPE) failures, 205 shortage of network resource, and etc.. Practical actions that 206 service providers can do is to set an objective percentage of 207 serviceability and try to keep that percentage as possible as they 208 can. An objective percentage of serviceability may be contracted 209 between a lightparh service provider and its customer as a single 210 item, or may be included in the concept of availability. The way to 211 show customers serviceability depends on service provider's policy. 213 In order to maintain serviceability, DoS should be considered. DoS is 214 categorized into two. One is the DoS caused by the network side, for 215 example, network equipment failures, shortage of network resource, 216 and etc.. The other is the DoS caused by the user side, for example, 217 CPE failures, destined end points being in use. From an SLA 218 perspective, the network side DoS and the user side DoS should be 219 distinguishable. 221 As mentioned above, one possible cause of the network side DoS is 222 shortage of network resource. If network resource is left little and 223 someone tries to create a new lightpath, DoS might occur. To prevent 224 this situation, network resource should be always monitored and some 225 proactive action should be taken (for example, NMS alerts shortage of 226 network resource when remained resource becomes less than 10%). 228 Another aspect of DoS is DoS attack. DoS attack means that a 229 malicious person continue to create a light path destined to some end 230 point so that other persons cannot create a lightpath to that end 231 point. In order to avoid malicious persons, users of lightpath 232 services should be identified, authorized and managed by a service 233 provider. 235 6.4 Accountability 237 In order to keep accountability, entities should be identified 238 whenever they use lightpath services. In addition usage history of 239 each entity's billable actions should be recorded. 241 6.5 Authenticity 243 To ensure authenticity, passwords, digital signatures, biometrics 244 and etc. should be used between entities and a service provider. 246 6.6 Reliability/Availability 248 To make lightpath services reliable, MTBF and MTTR of the total 249 lightpath system should be calculated, and managed by each service 250 provider. 252 6.7 Ethics 254 In order to protect the rights and legitimate interests of others, 255 appropriate rules should be applied to users of lightpath services. 256 Those rules may be on contracts. 258 7. Security requirements for business models of lightpath services 260 As mentioned in [ASON-UNI], layer 1 carriers lease a point-to-point 261 service to customers. Layer 1 carriers cannot make any assumption 262 about the business of their customers. A lightpath consists of a set 263 of wavelength links, and links are connected with OXCs. 265 From customers' view, customers construct user networks on the layer 266 1 network which is leased from layer 1 carriers. Customers can 267 construct any type of user network and can provide any type of 268 services. 270 The lightpath service is a layer 1 service, not layer 2 or above. So, 271 customer can do business using any type of networks including not 272 only packet networks but also circuit networks. 274 The path of light is able to be changed dynamically with some 275 signalling protocols. 277 Followings are some major business models using lightpath services; 279 (a) ISP owning all layer 1 infrastructure 280 ISP provides client service on its own layer 1 network. The ISP is 281 its own layer 1 carrier and uses lightpath services for itself. 282 Therefore there is no security issue between the layer 1 carrier 283 and the ISP because they are the same entity. However internal 284 security issue in the carrier exists. Only authorized persons 285 should be able to change the configuration of layer 1 network. 287 (b) ISP leasing partial or whole layer 1 infrastructure 288 ISP provides client service, but leases partial or whole layer 1 289 network from layer 1 carriers. There are security issues between 290 the layer 1 carrier and the ISP. Prior to offering the ISP a 291 lightpath, the ISP should be identified and authorized by the layer 292 1 carrier. Any billable deeds of the ISP should be accountable 293 while the ISP uses a lightpath. On the other hand, the layer 1 294 carrier should keep confidentiality and integrity of the ISP's 295 data. the layer 1 infrastructure should be reliable as well. 297 (c) Retailer or wholesaler for multi-services 298 The Customer (retailer/wholesaler) leases layer 1 infrastructure 299 from layer 1 carriers and again sells it to others. Between the 300 layer 1 carrier and its customer, the same security issues as in 301 case (b) exist. Between the customer and the customer's customer, 302 certain security issues apply. However this relation ship is out of 303 the scope. 305 (d) Carriers carrier, or bandwidth broker 306 The customer leases layer 1 infrastructure from layer 1 carriers 307 (carriers carrier) and uses it as its layer 1 infrastructure. The 308 customer network is likely to be a circuit network. The same 309 security issues as in case (b) exist. 311 8. Acknowledgment 313 The authors would like to thank Susumu Yoneda, Eve Varma, John 314 Ellson, and Siva Sankaranarayanan for their helpful comments on this 315 work. 317 9. References 319 [ITU-ASTN] ITU-T SG13 Draft Recommendation "G.astn; Architecture for the 320 Automatic Switched Transport Network", work in progress, 321 November 2000. 323 [TMM] Ivan P. Kaminow et al., "OPTICAL FIBER TELECOMMUNICATIONS III 324 A", p.280, 1997. 326 [ASON-UNI] Curtis Brownmiller et al., "Requirements on the ASON UNI", AN 327 SI T1X1.5/2000-194, October 2000. 329 10. Security Considerations 331 This document discussed general security requirements for lightpath 332 services. In each prerequisite, further study in needed in order to 333 implement secured lighpath services practically. It should be noted 334 that the listed security requirements apply to all kinds of automatic 335 switched layer 1 services offered to users, not only to lightpath 336 services (e.g. SDH/SONET TDM services). 338 11. Authors' Addresses 340 Hirokazu Ishimatsu 341 Japan Telecom Co., Ltd. 342 2-9-1 Hatchobori, Chuo-ku, Tokyo 104-0032 Japan 343 Phone: +81 3 5540 8493 344 Fax: +81 3 5540 8485 345 EMail: hirokazu@japan-telecom.co.jp 347 Shinya Tanaka 348 Japan Telecom Co., Ltd. 349 2-9-1 Hatchobori, Chuo-ku, Tokyo 104-0032 Japan 350 Phone: +81 3 5540 8493 351 Fax: +81 3 5540 8485 352 EMail: tnk@japan-telecom.co.jp 354 Zhi-Wei Lin 355 Lucent Technologies 356 101 Crawfords Corner Red, Room 3C-512, Holmdel, NJ 07733-3030, USA 357 Phone: +1 731 949 5141 358 Fax: +1 731 949 3210 359 EMail: zwlin@lucent.com 360 Yangguang Xu 361 Lucent Technologies 362 21-2A41, 1600 Osgood Street, North Andover, MA 01845, USA 363 Phone: +1 978 960 6105 364 Fax: +1 978 960 6329 365 Email: xuyg@lucent.com 367 Juergen Heiles 368 Siemens AG 369 ICN TR ON BS, Munich, Germany 370 Phone: +49 89 722 48664 371 Fax: +49 89 722 31508 372 EMail: juergen.heiles@icn.siemens.de 374 Yang Cao 375 Sycamore Networks 376 10 Elizabeth Dr., Chelmsford, MA 01824, USA 377 Phone: +1 978 367 2518 378 Fax: +1 978 256 4203 379 EMail: yang.cao@sycamorenet.com